G120 Loading firmware

We also started by removing the G120 from a board ( turning it in a “ikea” package) and the put a new one on the PCB by hand, raised a bit from the PCB with 3 layers heat resistant tape, and then started to just solder power, USB client, ldr0+1 buttons and the reset circuit. tested boot modes, debug and boot loader ok :smiley:
Then step by step starting adding CAN / UART / USB Host etc… just the things we absolutely need to give live (tomorrow afternoon…) and we have just 2 items open, ADC en RTC that we need to add and check tomorrow morning… but boot loader and debug interface is working as it should be, we are able to flash the board and apply the software so :smiley:

At this time started with 10 G120 modules we are on PCB version 2.0 with 1 working PCB and i have 1 G120 module left in stock… Geting close :stuck_out_tongue:

Any pointers for achieving reliable firmware loading on the G120?

I found FEZ_Config_v011 and GHI_NETMF_Configuration_Toolv003 not the most reliable when trying to update my G120HDR and G120 modules, and I had to recover the G120Updater from the 4.2.9 release (deleted by 4.2.10), which seems much more solid.

I had two G120s to try on my custom PCB, the first turned out to have bad memory and is on its way back, the second didn’t have that problem, but I’ve found deployment and debugging from VS2010 has other problems. It appears that the debugger isn’t catching things properly on startup. When I “step into a new instance” somehow a secondary thread can fire up before the debugger catches the main entry point. I put a 100s timed loop at the start, printing out debug messages once per loop, before any other threads are started which seems to give it time to catch the application, but it all seems a bit random in behavior at present, nothing like the clean debugging I’ve had with several EMX based boards.
It does seem things work better on the first run after a clean Erase/Upgrade of the module, as if running even a simple application is leaving something troublesome behind.
I’ve just ordered another 10 modules so I’ll have something to compare against (in case the module itself has problems). I have a few cleanups to do on the PCB (I missed the change of the MODE input from how it was on the EMX), so any gotchas others have found in PCB layout would be nice to hear about too.

About the same story over here, I also use the G120 Updater 1.04 at the moment.

Debugging with VS2012 (sometimes) has some strange behavior but nothing where I can put my finger on until now.

Following up on my previous post, the ten new G120s arrived, I installed the first one, and it has now been running continuously for two days with no problems.

This time I went step-by-step in David@ Emrol’s fashion, connecting at first only power and USB, then connecting each board component one at a time and testing, however I now have everything connected and running. Debug over USB and COM works, and I have seen no register-dumps over the COM port at all.

The usual minor software hitches found and fixed - eg default ADC precision has changed from 10 to 12 bits, which threw the battery-level measurement out, but nothing major so far.

@ David@ Emrol - did you get to the bottom of the inconsistencies you were having with your modules? The two I had problems with were labelled “Batch 825” on the bags, if that is a clue. The latest ones don’t have a Batch number, but are labelled “4/26/2013” instead.

My first set was from batch 2201, and we are testing our V3.0 pcb with modules from 4/26/2013. Some of the strange issues we had were related to the startup behavior from IO’s that are original assigned to the LCD, we created a workaround by ignoring these until they are initialized by the software and used 1 IO to give a go to the surrounding electronics after these pins are assigned.

Deploying sometimes “hangs” in debug mode, sometimes you have to wait for a minute, sometimes you need to reset the board to get going, but this is like 1 out of 50 runs or so.