G120 looses config again

As all the previous days i want to start and continue my work on a device using the G120.
I did not had much problems with the device since the last firmware update
The application in the device has not changed for a few weeks and works as a pipe between com1 and a spi port.

But today it happened again, the device stopped responding. A re-flash of config.hex was necessary to get the device running again. This application does not use Ethernet, its a simple application receiving/sending data from/to com1 and forward it to another device connected to an SPI port.

Scary :frowning:

buy an extra car, hire an extra service employee and let him drive through the country re-flashing devices at customers.

I bless the day i have something more reliable as G120 and / or netmf 4.2

when i started netmf and pre-made hardware I was thinking that this would increase productivity and having products faster to market. The opposite seems to be a reality.

Especially if you know that a new netmf version could solve a number of issues.

We nailed all bugs and even this one gotten a lot better, we thought it was fixed. This is high priority for sure.

And it may introduce new issues. It is very important we have a very stable 4.2 and that is what we are working on. We are very close.

Are those solved in 4.3? If not we will skip and right to 4.4 or we will tackle these issues in our own.

If 4.2 is very stable then commercial users do necessarily favor going to anything newer. As of now there are couple isolated issues on 4.2, which we will address.

Do you know the way to reproduce that ?

@ Dat - Not really, i was using the G120 board for a few weeks without problems or making changes to the netmf app. I was just working on the hardware/firmware of another board (not netmf related) connected to SPI of the G120. I had the G120 switched on/off for a couple of times today and at one moment it stopped working.


By switching on/off i mean plug / un-plug the USB cable from USB Client 1.2 SP module
Might be interesting to note that com1 RX pin was either high or low during power down. I am not sure of the state.

@ RobvanSchelven -

when you plug it back, do you see its friendly name on MFDeploy or not?

@ Dat - Do you mean after crash, when it does not restart anymore?

when the board “crashed” and needs a re-flash of the config.hex i set LDR 1 low and use mfdeploy, with LDR1 low i can see the friendly name.
After a crash the PC / mfdeploy does not recognize the device when both LDR0 & 1 are high.

@ Dat - An errata sheet of the LPC1788 ( http://www.nxp.com/documents/errata_sheet/ES_LPC177X_8X.pdf ) mentions

During power-up, an unexpected glitch (low pulse)
could occur on the port pins as the VDD supply ramps

Could this issue force the device in a state that only can be reset by reflashing the config.hex?

This is unrelated to the issue we have I believe.

@ RobvanSchelven -

  • Are you willing to reproduce this bug if we send you a test version?

@ Dat - Sure, i can give it a try although its hard to predict if, and or the issue shows up again. As i wrote, the board was running for a few weeks without problems. It make sense if you guys know that the firmware contains changes that are related to this issue.

@ RobvanSchelven -

Once time it happen again, don’t re-flash it. Let me discuss with my team if there is any way to read some config from TinyBooter with FEZ Config tool.

TinyBooter still works, right?

@ Dat - Yes, tinybooter still works