Main Site Documentation

G120 looses config again

#1

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 4.2.11.0
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:

#2

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.

#3

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

#4

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

#5

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.

#6

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.

#7

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.

#8

Do you know the way to reproduce that ?

#9

@ 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.

Update:

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.

#10

@ RobvanSchelven -

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

#11

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

update:
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.

#12

@ 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
up.

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

#13

This is unrelated to the issue we have I believe.

#14

@ RobvanSchelven -

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

@ 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.

#16

@ 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?

#17

@ Dat - Yes, tinybooter still works