StrangE issue with SoC cc2510 and cc2511 hanging

It's a little difficult to know exactly what the problem is.  When you create the conditions artificially, does the flash still get erased?  Is it possible to run in this fashion with the debugger and attempt to see where the code is hanging?  Can you tell me about the code, where you got it?  Can you share it with us?  Any additional information would be helpful.

Jim Noxon

Yes the flash is damaged somehow buy the rapid inrush current of the jammed motor 1A.there is no way of going back,reseting is useless,only re flashing the SoC will solve the problem.there is a moment when in more than 100 test the chip dosnt hang, and in others moment does really yesterday night i test more than 1000 times and didnt hang,today moorning hanged once,and so on the rate3/100 is not really all the time observed.but the fact is that hangs and it shouldnt.to solve it i placed an other mcu with the only function of checking the posible rare hang event and willl re-flash it again ,is not profesional but is practical The SoC is intended for 4years work in wild nature conditions and high reliability is needed or the device Also there is another hang issue with uart0 19200 b/s that hangs and get corrupted after some 6 hrs but is ok because of the error rate margin accepted of 0.004% i guess

Are you doing any dynamic storage of data to the flash?  If so, could the loss of flash information be correlated to this operation?

When the motor gets jammed, is this generating a large spike on the power lines of the radio part?  Can you isolate the supplies between the motor and the radio.  Do you have any scope traces of what the power supply is doing when the motor jams?

I cannot think of any reason for the flash to be corrupted unless the failure is happening during a flash write.  I suppose it is possible the chip is entering debug mode when the motor jams but there are plenty of required operations in this mode to cause the flash to be written and the probability of that happening is so remote as to make it practically impossible for it to happen once, let alone multiple times.

Can you think of any other correlation between what is happening in the code and the flash being erased?

Have you read out the flash image to do a comparison with the original code image to see where the differences occur?

Is the motor jamming due to some code failure (like an ISR hanging or not being triggered) or is it from an external event like a mechanical blocking due to debris or something?

The more information you can provide the better I can help you.

Jim Noxon

Thanks The motor jam for mecanical reasons and that create the spikes,countles times the event happens without any episode of hanging.at the begining the hanging process "burned" two hbridges because the hbridges were not protected against the case 1 1 signal coming together at once , because when the hanging freeze episodes happen that all lines are input with pull-up giving a signal 1 all the times :-). (later i added a circuit protection interlook to evoid that) I removed the power ,wait,later connect the power and nothing happens the Soc still frezzed giving the all input pull-up all the time,,sreseting power on off and normal reset shorting the reset to GND didnt work at all,the only way: reflashing it Once happened that the SoC didnt respond at all to flash and was considered "burned" (i could read the chip ID but i was no able to write into flash) I did not recover the flash image back for comparisions and checking,maybe i should do it

Were you able to validate the flash image after a hang?  Was it corrupted?

Jim Noxon