Gus, I can confirm it still reboots. My test application does nothing but set the backcolor, clear screen, draw text and refresh.
Total boot time is 28 seconds!
After about 25-26 seconds MFDeploy sees this
*** nXIP Program found at 0x0000
At which point my PC reports the Cobra II becomes unavailable for about 1/2 a second then then available again with the remaining 2-3 seconds being used by normal start-up (displaying GHI build info).
I FOUND THE ISSUE!!!
OK, this one is slightly weird but Iāve found the way not only to reproduce the issue, but to fix it as well.
Freshly update the firmware on any Hydra/Cobra II (assumable other GHI devices as well)
Program board (make sure you cause the screen resolution to change!)
Every time you restart the device it will take ~30 seconds
Now for the fix:
Simply reprogram the device. Thatās it. If you deploy the same application (any application) a second time, the issue goes away.
It [em]should[/em] be happy! 
Iāve been watching exactly the same code run on Cobra II w/ WiFi & CP7 and the Hydra with Ethernet and T35. I canāt get enough of watching my new BIOS do itās thing.
We are still unable to reproduce the issue, even when following the steps you gave. Just in case, can you post a minimal code file and the contents of your project file?
I am interested in trying Glide on the Cerberus, and according to the new SDK that should be possibleā¦
Can anyone guide me to some good examples or documentation and what is specific about the Cerb?
Glide will not work on the Cerb because is built assuming that the graphics device is an LCD display with a full LCD driver/interface. the Cerb only works with display devices that use a SPI interface. SimpleGraphics work as long as the Gadgeteer driver implements the Paint function (which the N18ās does).
Makes sense, but I am still interested in examples showing the improvements of the new SDK for Cerberus and small displays.
Iāll have to add to this. I updated two G120ās to the latest SDK and then programmed the LCD and now when you power on it takes about 30 seconds or more before the display shows anything and then the application starts.
If you have debugging plugged in, itās the same and there is an initial beep from the PC as it detects then about 30 seconds or so there is a disconnect and reconnect and then I am able to debug.
As the backlight enable is pulled high, I am left with a white screen until the display is enabled. If there is no fix for this forthcoming, I may need to disable the pullup so that the backlight remains off but that leaves the user thinking there is no power on the unit.
This is using a Newhaven 5" capacitive LCD. The G120 on the Cobra 2 board with a TE35 does not appear to do this. It starts very quickly.
@ Dave McLaughlin - what you described is perfectly valid on first power up. The display is disabled by default. It should not happen a second time add long as you have a valid config.
Hi Gus,
Itās doing this more than just the first time. Itās doing this every time I boot up with this panel.
I only have basic code to test the display and touch are working. There is no core application as yet.
@ Dave McLaughlin - Ok good, please share the code you have loaded on the device. Which I suspect is LCD initialize code followed by a simple draw to the screen if no reboot is necessary and a reboot if necessary.
Hi Gus
There is no LCD code. I used the Fez Updater to set the LCD and use Skewworks CLIX2 for the graphics.
Thinking about this, I will try a Glide test before I confirm this issue. After seeing Thomas seeing the same thing, I am wondering if the issue is elsewhere.
Give me a day or so to write some test code and confirm this.
Please do not use any code but a simple bitmap that you flush the screen. If that works then we need to see why skewworks code is causing this delay.
Hi Gus,
Here is a short video demo. Iāll send you the code for the left display which uses only a bitmap with a rectangle drawn in it.
As you can see, the basic demo and the Skewworks are taking the same time to boot. Almost 30 seconds from switch on.
Both are running without a debug connection. It takes just as long with debug connected.
Thanks for the video but what we really need is the code o we can repro on our e3nd. We tried but was not able to repro before.
Hi Gus,
Iāve sent the code. Let me know if you donāt receive it?
Daveā¦
@ Gus - Clix 2ās startup code is pretty straight forward. It hits the hardware provider to get screen metrics and than initializes touch.
Iām guessing SimpleGraphics also hits hardware provider to check the metrics, perhaps that might be were the issue is coming from since just declaring a Bitmap at a specific size wouldnāt make that hit.
The point here is that we are not able to repro the issue on our end and trying to narrow it down so something easy to track. We will try the code we received and hopefully we will be able to repro.
We tried the code you sent and are still unable to reproduce the problem. What exact steps do you take to reproduce the problem starting at a completely blank device with no TinyBooter or TinyCLR?
Has anyone been able to get a Cerberus based device running outside of debugging? I updated my palm monitor but now it only runs if Iām running it from the debugger.