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