STM32F101 is not responding to reset

[mustafa]

Posted on February 14, 2015 at 07:42

Hi,

We have a trouble with STM32F101. 

We used STM32F101 for far field device. It passed all EMI/EMC test for CE, then we started to field installation.

After a while, server communication was lost with some devices.so we went to the field. We saw the device's power LED is lit, but the device did not work. We opened the cover and took the reset pin to ground, but STM32F101 not reset. Then we cut off the power stm32f101, started working properly again after connecting power.

But this process is not acceptable for a remote device.

STM32F101 as in an unexpected situation. What could it be, how a solution can be found?

#stm32f101 #nrst-pin-problem-trouble-stm32

[AvaTar]

Posted on February 14, 2015 at 16:41

We opened the cover and took the reset pin to ground, but STM32F101 not reset.

 

With utmost probability, this is an unproven assumption, and IMHO not correct.

The MCU not behaving as expected after reset is much more a function of your application code and internal states. Pulling down NRST does not reset the internal RAM, only the core and peripheral registers, as documented in the reference manual. Power-cycling most probably does.

I suggest you either try to reproduce the issue at the factory (your lab etc.), or wait for the next event in the field. Catch with the debugger at the reset vector, and debug. That would, of course, require debug access. (I'd really wonder if it has not readout/debug protection enabled when shipped ...)

My assumption - your application has a runtime problem. Perhaps a stack overflow or deadlock under rare conditions.

Consider some stress-tests over longer periods for your (undisclosed) application.

[mustafa]

Posted on February 14, 2015 at 18:07

We think it could be a software problem, but we were unable to perform in the laboratory. No debug connections on the device, The device is programmed via UART0 so unable to debug. If the problem is related to RAM, what is your suggestion?

Not everywhere, in almost the same environment we met multiple times with the same problem. So we thought it would also be an EMI problem. Do you think this could be the problem?

[Tesla DeLorean]

Posted on February 14, 2015 at 20:25

NRST should allow you to reset, how is it wired in your circuit.

If you can't use JTAG/SWD connectivity to debug perhaps you can output diagnostic information out the serial port. Do you have a Hard Fault handler? Can it output via a status LED? Or send a looping message out the serial port?

Perhaps the power supply is glitching, do you have an effective power-on-reset circuit externally?

Do you use the watchdog timer?

[mustafa]

Posted on February 15, 2015 at 16:20

4K7 pull-up  resistor at NRST pin.

A status led is used but not blinking.

Not responding to 4 UART channels (UART0, a module connection,  RS232 and RS485 converter)

3V3 is smooth, STM32 also work properly after re-power on.

Internal watcdog and hard fault handler are used. In this situation an external watchdog is also useless because NRST is not working.

[AvaTar]

Posted on February 15, 2015 at 17:32

3V3 is smooth, ...

 

Under all circumstances, in the field ?

Tested with all temperatures the device is specified for ?

...because NRST is not working.

 

This is simply not true.

A reset is unconditional, if the conditions as described in the datasheet, are met.

As mentioned in my first post, the difference between NRST reset and power-on reset is the state of RAM and certain MCU registers, which are NOT initalised (see the reference manual).

I'm pretty sure, because of these states, your application runs into an untested code path and gets lost.

[Tesla DeLorean]

Posted on February 15, 2015 at 17:40

because NRST is not working.

You keep asserting that, but I'm not wholly convinced.

Do you have anything driving NRST with a push-pull driver? Do have code early enough in ResetHandler to know it hasn't got there, or do you have code further down the path that is failing? Do you have any circuitry that would detect a brief power supply failure? You're not likely to see brief/intermittent failures on a scope.

[mustafa]

Posted on February 15, 2015 at 20:09

Hi,

Firstly, thanks for your interests.

Only a pull-up resistor at NRST, maybe it will be better with a 100nF cap. 

''because NRST is not working.'' I mean: It is not restart STM32 as I want. So the external watchdog also will not restart as I want. Maybe it is because of RAM or not. Do you agree with me?

As I mention, I don't know what happened in there, 3V3 is smooth when I went there and measured it. (Conditions are normal when I measure it, but STM32 is not working at that moment. This is the issue) 

I continue to check the code again and again. I'll double check your advices.

Not everywhere, in almost same environment it happened, so I think it might be a non-software problem. Maybe voltage regulation (220V AC with flyback) problem or EMI/EMC problem had happened. I'm not sure but I'm trying to achieve by eliminating possibilities.

If it is software issue, it is OK. Only a software update is enough. But if the problem is STM32 , there is a big problem. This is the reason of my curiosity.

[Tesla DeLorean]

Posted on February 16, 2015 at 02:59

Well you really need to get the reset problem identified and corrected. This should be your first priority.

If it were me, I'd start by adding some code in ResetHandler to better identify if it was getting there, or not. If it's really not getting there then we need to look for some electrical issues.

The code in SystemInit() (system_stm32f1xx.c) needs to be reviewed, you need to see if the external clock and PLL are starting properly, if you are using them. You also need to identify if it gets to your main() routine.

One way of doing this would be use the USART and identify waypoints, or using LED or GPIO sequences.