I have a problem that randomly pops up - the unit crashes so hard that even a RST (pin 14) won’t work. I have to do a power cycle to reset it. Anyone else seen this? Any ideas as to the cause?
-Erik
I’m developing on a connect me 9210 (Netos74) and am also experiencing a similar problem. I’ve been able to get the unit to consistently fail. The problem seems to lie in the main() function call of src/bsp/common/main.c. This code gets called right after the bootloader decompresses the application image into ram. If I attempt to reset the unit by driving pin 14 low during the execution of the main() call, the unit goes into some unknown state that can only be recovered with a hard power cycle. I’m not sure exactly what in the main() function call is causing this, but the unit has always been able to reset properly when it’s not in the main() function.
I tried replicating it here, and I wasn’t able to get it to fail. How are you ensuring it happens in main()? Are you running it through the debugger or from flash?
I get it randomly in the first five minutes after the ME -C has started. What is funny is that if it lasts more than five minutes, it never crashes. I have only seen this 6 times on my bench (out of hundreds of boots), I don’t know if this follows in the field. I suspect so from some of my customer complaints.
The ME 9210 code I am working on seems fairly stable except for a wierd crash which I will start a new thread on.
I was toggling LEDs when entering and leaving main(). I’m not using the debugger. My real question is: What does the reset via Pin 14 really do? What is the sequence of events when Pin 14 is driven low?
I forgot to mention that the window of opportunity is approximately 300ms. It make take a few tries but eventually the unit will freeze. I’ve gotten the unit to freeze just be pressing the reset button on the development board during the 300ms window. Once the unit freezes up, only a hard power cycle can reset it.