G400 Beta kit looses firmware... Again and again?

Technical details first:

  • G400 beta kit;
  • Modules: ENC60 (socket 6), CAN DW (socket 7), and a custom soldered FRAM on SPI0.
  • DP power module, connected both to PC and a 24V power supply;

I’ve ported my program from EMX system we use now (was quick and painless, by the way — NETMF haters in our company were shocked), which analyses ~1000 CAN messages per second, and is also communicating with PC via LAN.

For a couple minutes, everything works just totally fine. But then, for some reason, G400 freezes. After a reset, my firmware is not executed at all. Instead I see “ABORT Data” on the screen (check the attachment).

Now, the funny part:

  • Windows (7&8, 64bit) shows “device unrecognized” message, and there’s an “Unknown Device” in the Device Manager. Obviously, I cannot deploy firmware to it anymore.
  • I can, though, put G400 to TinyBooter mode, by holding LDR0&LDR1 and pressing reset!
  • The only I can make thing work again is only by reflashing everything, including TinyBooter, from scratch, as shown here https://www.ghielectronics.com/docs/112/g400

So… Any ideas?..

By the way, in TinyBooter mode, I can erase the firmware; updating firmware fails, though (Using Firmware Updater from FEZ config 013)

@ Simon from Vilnius -

From G400 Known issue

How about if try at 2nd time?

@ Dat— aha, so that’s where this “update two times” issue applies! Now I get it. I can revive the G400 without reflashing TinyBooter.

However, the firmware still gets corrupted in minutes…

This is good! Can you sow us some code that cases the firmware to get corrupted in minutes? We need this to make sure we have the issue resolved.

Well, the whole program is about 60k, and I don’t even know which part causes trouble :slight_smile: I somehow have a feeling it is related with LAN. If I send lots and lots of requests via LAN, G400 sooner or later freezes.

I will try to detach some parts of the program to see if that changes anything.

@ Simon from Vilnius - Do you use sdcard in your application ?

No.

@ Simon from Vilnius

You show that you have several modules being used. Are you using a console project or the custom Gadgeteer interface? Can you remove a module one by one and also remove the respective code to isolate the potential problem?

I got the exact same issues yesterday when I was attempting to port my ChipworkX application to the G400.

I disabled all of the SD Card access as the current PCB does not have the correct wiring for this.

After a few seconds I got the same error as Simon. I could not reboot it would go straight to the same error.

I had to reflash TinyBooter and the firmware to get it working again but it did the same shortly after the code was running and I have not been able to determine where in the code this happens as it is quite tedious having to reflash each time it happens.

I’ll be back on it tomorrow so will report what I can find then.

It seems that the Eth ENC28 (network) is the problems. I’ve detached code and hardware relative to SD, maintaining just ENC28 board. I reflashed firmware, to start a clean condition. I keep T35 display attached. I need always 2 round for flashing fw: 1) it stops at erasing address, 2) need reset button, start again and finally fw is flashed.

Running VS2012 debug went fine and board works ok, debug works ok. I stopped debug, forced recompile (same code), started again debug and boom fw crashed after the end of ProgramStarted(). Program started just setup ethernet fixed address and gateway.
The erase application feature of FEZ Config doesn’t work.
I think that something wrong happens in the config settings inside the fw …

Agreed. I can even kill the firmware in two ways:

  1. I leave the full system (CAN, LAN and FRAM), turn it on, send some packets over LAN. Eventually G400 hangs. Now, if I just click RESET button, G400 usually reboots and works again. If I unplug the power cable — it’s dead.

  2. I leave only LAN, and start plugging/unplugging power and LAN cables. In a minute, G400 firmware is corrupted. The last cable I touch is always the power one.

@ dobova - not sure if this work for G400, since i don’t have one… did you re-flashed the whole firmware or just config.hex. I’m curious if its 'the same kind of problem as with G120 where config gets corrupted now and than after write actions (mainly caused by a call to SetStaticIP(…)

Also, if anyone is interested in power line… If I:

  1. Connect ENC60 module and use LAN;
  2. Use the DP power module with +24V and USB cables connected;
  3. Plug/unplug USB cable every 5 seconds, after 5-10 operations I get a negative spike on the +3.3 line (see attachment). G400 hangs, if I repower it — firmware is gone.

I was unable to repeat this behaviour without ENC60 module and a simple blink-the-led application.

Also, only GHI firmare goes wrong. My application seems to remain untouched — if I reload GHI firmware with FEZ config, application seems to work fine without deploying it again.

@ RobvanSchelven I’ve tried just now. Looks like reflashing config.hex is enough to get G400 working again.

I confirm that flashing Config.hex repair the situation.

Interesting … Gus wrote last week that they might have found something related to that corrupted config and G120. Keep my fingers crossed, although we have to realize that it might be something else with G400. I also believe that the problems is related to voltage drops in the 3.3 volt power.

I think the same problem is going on G120 or at least similar lthough not so frequent.

@ RobvanSchelven -
I’m not in lab and I haven’t with me a precise multimeter, but I don’t see any serious voltage drop with ENC28 attached … That’s may be a major issue for SD that is very critical on voltage supply.

@ Simon from Vilnius - from your image i can see that the voltage is 3.12 volt… I have done some testing and see problems arrive at G120 when the power supply is at 3.24 volt or lower. At 3.3 volt i haven’t seen problems over the last days. I haven’t studied the micro controller datasheet / memory interface but i can imagine that timing is set to tight. Lets hope for a quick solution from GHI