One other thing I do recall, is booting into Tinybooter and erasing first, update Tinybooter and then reboot and run Fezconifg. I did this same step on both the boards that show this fault. I had to do this as Fezconfig refused to update the firmware and give me an error after a long wait. Something like 2 mins waiting. After TinyBooter was updated, FezConfig worked.
I then updated the G120 modules to the latest firmware though FezConfig. I then set the LCD through the same application and then powered off and back on.
After the 30 seconds or so, I get the debugger connection. Download the application I sent you and then run it. Disconnect debugger, remove cable and power off the board.
Power it back up and wait the 30 seconds as shown on the video.
Got my palm monitor running again as it seems adding an ability to the network connection to grab a static IP if the dynamic one failed has got me back online at:
Just as a test, I decided to do the same process on one of my Cobra 2 boards which is running with a GHI TE35 display.
1st TEST
Re-installed tinybooter and then firmware update. All went well. First run of the application setup the LCD and after this I could run the debug connection. Fast boot up.
This was using the application to do the initial programming of the LCD driver through Gadgeteer.
2nd TEST
Now I tried it all again and this time using the FezConfig to set the LCD after updating tinybooter and the firmware. After a reboot, I get a white display and it takes approx 20+ seconds to reboot in much the same situation as my custom board.
3rd TEST
I then went back to the first attempt and let the application programme the LCD. Now reboot is back to being fast.
Each time it takes 20+ seconds. All I see is a white screen.
Before the 3rd, I did an ERASE and reflashed TinyBooterand then the firmware. Basically the same process to load tinybooter and the firmware. The only difference is that I didnāt use the LCD config in FezConfig for the 3rd test.
@ njbuch those straight lines are bad and indicate that the monitor crashed and what Iām trying to solve. I was hoping that the new release contained some fixes as the monitor used to run for a couple hours before it blew up, but the last few tests have shown it blows up sooner then before. Still looking into this as time permits, but my palms arenāt happy about this at all.
@ Dave, additionally: uninstall the SDK, delete the GHI Electronics folder if it remains, redownload and reinstall the SDK to see if the problem persists. Make sure to reflash everything with the new SDK. Try a different computer as well if possible. What version and bitness of Windows and Visual Studio are you using?
Iāll give the uninstall idea a try this weekend. Not sure why the Windows installation would be the root cause as the device itself is the part that is taking so long to boot, even without being connected via a debug connection.
The only effect the install would have is if you somehow got a corrupted firmware, at this point with us still not able to reproduce, it is worth a try to eliminate that as a possibility.
@ Dave I was just able to reproduce the problem. When you used FEZConfig to update the LCD, did it tell you there was a device error with a code 0x0001 on the first attempt or two?
@ Dave When you plug the device taking 30 seconds to boot into a computer, does it show up in MFDeploy/FEZConfig right away? If it does, try and ping it. It might say TinyBooter. If it does, while the screen is still white and the device is in TinyBooter mode, goto Advanced -> Clear Bootloader Flag. That should solve the problem.
