reset circuit problem with stm32f4

[Moamen Ayman]

Posted on July 02, 2017 at 19:29

Hello, I'm using stm32f407vgt6 MCU in a control system and I'm facing a strange problem in the reset circuit, when I power on the system it doesn't start until I put a short circuit wire manually between reset pin and GND and then remove this wire so system can start properly. system's external reset circuit consists of pulldown 0.1uF capacitor and pullup 10KOhm resistor. I have tried to replace the 10KOhm resistor with 100KOhm but nothing changed. I also replaced the 0.1uF capacitor with 1uF and also nothing changed. Could someone help me to find out what may cause this problem and why I need to connect the reset pin to ground for just a second in order for the system to start?

Thanks so much in advance

Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Moamen Ayman]

Posted on July 08, 2017 at 09:10

when I connect the PC to the PCB through USB so GNDs should be connected together but the problem still exist, in this case the PC recognizes the system as a virtual com port (COM5) and in my code the USB peripheral is initialized in FS mode at first part of the code and that's why I am thinking that the processor start working but it doesn't continue executing the rest of the code but why when I connect the NRST to GND it start and continue without any problems? 

[Moamen Ayman]

Posted on July 08, 2017 at 09:11

all power pins works at 3v and CAP pins 1.26v

[T J]

Posted on July 08, 2017 at 10:02

' when I connect the NRST to GND it start and continue without any problems?'

that should cause the problem.

' unexpected reset and program counter corruption can be

reproduced by manually forcing a low state on the NRST pin or the Oscillator pins for 1 second.' ref:page 110/201 DocID022152 Rev 6

what does the PCB do with the Oscillator pins ?

what is the primary power supply ? 12V, switched down to 3v3 ? or a 5V charger ?

[Tesla DeLorean]

Posted on July 08, 2017 at 15:28

I don't know.

Holding the NRST low for several hundred ms doesn't help, but you can down load code and run in debugger.

You need to look at pins and clocks the debugger enables that you might not be. Look at DBGMCU settings. Look at HSE and PLL code. Look at behaviour that could be impacted by component tolerances/differences.

You REALLY need to get serial output (not via VCP) so you can diagnose code flow and status WITHOUT attaching the debugger. Instrument the code and have a Hard Fault handler that outputs useful data.

You want to be looking for timing critical loops, or other things where the debugger may have changed timing or responsiveness of the system.

You need to move beyond focusing on the one-second NRST, and start examining what's actually happening.

[Damon Gibson]

Posted on February 06, 2018 at 18:10

Hello Moamen,

Did you ever solve the STM32F4 reset problem you were having?  If so, what did you do?

I am having a similar problem with an STM32F469IG MCU.  Our code appears to start after power up, but many of the communication ports (CAN, UART, USB, etc) either don't function or are very unreliable.  In every case, briefly connecting nRST to GND, to reset the unit, fixes the problem and the firmware then runs perfectly.  Like you, none of these problems occur when running under a JTAG debugger (presumably, because the IAR EWARM debugger sends a hardware reset at the beginning, which simulates touching nRST to GND).

We worked around the problem in a unique way by adding some logic to a Lattice FPGA on our board.  The FPGA is connected to nRST and our FPGA logic sends a 13.5 mS low pulse to nRST after power up.  This again makes our firmware (and all communication ports) run perfectly, but I consider it to be an ugly band-aid to correct an undocumented problem in the MCU chip. (I looked through the latest Errata for the chip.)  I am convinced that a 'normal' power-up reset does not fully initialize all of the state machines in the MCU chip, requiring a 2nd hardware reset to finish the job.

Perplexed in Indianapolis,

Damon

[T J]

Posted on February 07, 2018 at 08:36

I had a similar issue on my board, until I found the Can Rx pin has to be pulled up..

usually the driver chip does that, but if the canbus drive chip is not installed, without the pullup, it will hang the processor...

you can comment out the   MX_CAN_Init();   from CubeMX : this fixed my reset-hanging issue.

oooo, yes,,,   and I added a reset chip !

[Moamen Ayman]

Posted on February 07, 2018 at 17:25

Hi Damon, 

 Yes I have solved this issue. After long tracking to the hardware and software I found that as you said it needs a rest pulse after a long time >10ms, basically the MCU starts normally and also continues normally but this was a problem in the code architecture. when I run any other codes, you can try yourself to run other simple codes on the same hardware you designed and face this problem with without the reset circuit you have connected, it will work!

My code was so heavy and uses many of the chip's peripherals and one of them (in my case was the RTC crystal) needs to wait long time to be initialized and sometimes it needs you to reset the code to allow it to work with other peripherals properly.

The solution is to use watchdog and assign a decounting number related to the maximum time you think is a little more enough for your peripherals to initialize and if some of your peripherals stooped it will automatically reset the MCU and does exactly what your rest hardware circuit do thus after it rest it will work normally.