Not responding to NRST input

[bvr]

Posted on May 12, 2012 at 10:18

I have a curious problem.  In one of our boards with stm32, because of some reason an external watchdog triggers (we are not using internal wdog for some reasons), the watch dog outputs proper signal to STM32 NRST pin, but the controller doesn't reset.  Unfortunately it is not possible to simulate the behaviour in lab.

However, on a power cycle the board resets properly and functions normally.I have a board in which the reset signal is being given to the controller for a week.Watching all the gpios on oscilloscope there is no change in the io states during the active reset signal input.  does it mean the reset is not being accepted by the controller?Power pins are in limits, boot pins at their right voltage levels, external oscillator running with proper voltage levels.  NRST signal goes below 0.2V.  What else? #reset-stm32

[Tesla DeLorean]

Posted on May 12, 2012 at 15:31

The common reasons for NRST to not function correctly are

Solder shorts. Being driven by a push-pull driver not an open-drain. Clock failure. Internal latch-up. Other issues could occur if the BOOTx pin state cause it to start into something other than FLASH (ie your code) when reset or exiting standby.

[bvr]

Posted on May 13, 2012 at 17:04

Thanks.

solder shorts, boot pin levels and clocks are fine as I have already written earlier. The input is being driven by a WDT chip (APX 825) whose datasheet doesn't specify the output drive type.  Is it essential that we drive NRST pin with a Open collector, even if the voltage levels meet the requirement and current sink and source specs are met? Yes, internal latch-up is one I am suspecting, but why? Is there a solution to prevent this.  Can any one from ST add to this?

[Tesla DeLorean]

Posted on May 13, 2012 at 17:51

ST has approaching zero participation on this forum, purposefully it seems. Call your local Rep/FAE if you want direct support.

NRST is a bi-directional pin in virtually all ARM systems, you drive it high with an external push-pull and you WILL have a bunch of grief, I've seen lots of people do this. I listed it because it's the number one reason why external reset circuits fail. You should perhaps review the STM32's reference manual and look at the ''Simplified diagram of the reset circuit'', to understand the ramifications. The part you cite appears to use a push-pull driver capable of driving high at 20mA, the STM32 will have a hard time getting that close to ground.

http://datasheetz.com/data/Integrated Circuits (ICs)/Supervisors/APX825A-31W6GDICT-datasheetz.html

If you expect reset problems, use some GPIO pins to signal various stages of your reset path/execution. Do not attach a debugger, these interfere with ''normal'' operation.

[bvr]

Posted on May 14, 2012 at 06:22

Thanks for your valuable inputs.  Will post back once we find a solution (it may take time as this is happening only in field, not able to reproduce in lab conditions).

BVR