To anyone’s knowledge or experience is it ever possible
that by running a Netmf 4.3 application on a G30 or by not powering the chip for a while
you can end up having to reflash the program?
The background to this question is that a customer just reported a bug in which he states that if the device is switched-off for an extended period of time then the firmware (the netmf app) must be re-flashed before it will work again.
I would say a good estimate for how long the device sits without power is one weekend. During the week it is power-cycled often: maybe 15 times per day, and used throughout most of the day.
In no part of my application do I attempt to read or write any part of ROM.
I do still have some bugs which seem to do with high-traffic IO. Buffer-overflows and things of that nature. In my experience this always leads to an exception that when un-caught causes the offending thread to cease execution. I have never found, myself, that restarting the system did not bring me to the beginning of the same application.
We have several hundred G120s in the field that where power may be turned off many months hot, cold conditions etc. Have never seen this problem.
…and hope I never do!
This is what I was afraid of… and I was reaching out partly to see if there was a chance that the underlying firmware ever manipulated the program memory. And maybe there was a known bug in such a portion of firmware. Or maybe the exceptions thrown some of my IO issues don’t always catch it right away… but I can’t see how that would ever affect ROM and not just RAM.
And finally, since the user claims they can replicate this issue on a single device (i failed to mention they have about ten and only found this to happen on one) by leaving it off for some period of time… I was wondering if there was some potential for failure in the manufacture of the ROM… and more importantly if anyone has ever had the same issue.
Have you ever got one back fro debugging?
Could it be something silly, like a buffer overflow or powercycle/shutdown, that is corrupting something external that the software relies on to start up, eg a config file or something sim. That once corrupt, causes and exception that the user would not be able to detect, but see’s the whole unit as dead. And a re flash fixes the issue as its resetting the state of those files?
I have not had the opportunity to test the failing device.
I can think of no part of my system that matches what you describe… nothing persists through power cycling… however, there are remote devices involved… and they both must be restarted to get a true system reset.
There is an overall radio timeout involved in my application. I should analyze the various states of my system to see if there is a way to permanently get out of sync… that is until the 40s timeout rolls around. I can turn the thing off and on way faster than 40s… forcing the timeout to never occur but flashing firmware (and consequently not sending messages of any kind during the flashing period) just might take that long!
An interesting lead… alas, why would they consider this to be caused by extended periods of shelf time?? hmmm