Not sure why. Must be something else.
There is almost no code on this. You can see how itās a problem
Iāve confirmed there is nothing wrong with the CP7 itself. Works fine on other firmwares.
This also works fine on the Hydra under the latest firmware so it looks like itās possibly Cobra II specific.
I can confirm Skewworks observations with several of my Cobra IIs and CP7 displays.
My Hydra with the CP7 attached gave me following.
Incrementally deploying assemblies to device
Deploying assemblies for a total size of 968072 bytes
Assemblies successfully deployed to device.
The debugging target and the debugger engine failed to initialize because of unspecified device errors.
The debugger engine thread has terminated unexpectedly with error āCould not reconnect to the debugging target after rebooting it.ā.
My Hydra application functions fine I just cannot interactively debug it.
We are able to reproduce. When you say it is corrected after the user flushes to the screen, do you mean the distortion goes away? If so, what method of drawing are you using?
Flushing from a normal full screen bitmap. Hereās the rub though, after downgrading the firmware and then reupgrading (testing IFU), Iām no longer able to stabilize the display under any circumstances.
Iāve gone through updating the CobraII at least 8 times over the weekend (manually, FEZ Config, IFU) trying to get it to run properly with CP7, no luck.
When you initially upgraded, you may have had old configuration values in memory still allowing it to work after flushing. After the re-upgrade, they were finally set properly. When I manually lowered the pixel clock rate from 40,000 to around 20,000, the display worked fine. Problem is, the clock will be reset every time the program loads. So you have to change the CP7 source. Line 247 in Display_CP7_42.cs, increase the pixel clock divider to 5 or 6, and it should work.
Excellent news!
I began working on pure NETMF implementations of Gadgeteer modules yesterday anyway so this should make it a real simple test for me. 
Iāll give it a whirl after Iām finished with the module Iām on and let you know how it goes, thanks for the quick turn-around time!
Pixel Clock Divider of 5 works great, thanks 
Glad to hear it.
Does this include a new firmware? I read previous that v4.2 should be used for commercial purposes, does this mean i shouldnāt use this sdk?
Iām not sure if your question refers to the SDK Package or to Skewworks product. If GHI SDK, then the answer is yesā¦ you will need to upgrade your mainboardās firmware.
Refering to SDKā¦donāt want to migrate to v4.3 if its going to loose functionality or loose support.
How long will GHI support v4.2?
The GHI team have NOT released a 4.3 SDK. Not sure why you think that. You can be sure GHI are still supporting 4.2
yepā¦was a bit confusedā¦i now understand its a v4.2 release
Is there anyway to speed up the enabling of the LCD?
Iām sure you guys made the switch by popular request, but these start times are brutal for me
It even seems to do an extra reboot.
The extra reboot only happens when there is a change to the LCD config only. And I thought we covered the boot up speed by fixing the clock divider?
The fix only made the display actually work, it didnāt do anything for the boot time.
Iām not 100%, but I think its continuing to reboot even after the initial programming. I can check into and get back to you.
Shouldnāt be any step at all involved in reproducing, just watch the USB on MFDeploy and you should see it come up, say its found a program, become unlisted and then a moment later show up again.
I know this is a big new change, so I expect it might be buggy at first no worries
I tested it many times but no issues. did you try it with a simple application?
Iāve tested it with several apps, including one that was 4 lines of code, all calling SimpleGraphics, but Iāll recheck against that in the morning. Like I said not 100% about the reboot issue but I am certain about the startup time. Its not deadly* but itās not ideal.