ST-Link not properly resetting STM32

GerhardLnf · ‎2025-08-08

Hi,

I am trying to solve a strange programming related problem I am now having after updating the reset circuit of my STM32F439-based board. Below is a comparison between my old and my new circuit:

The reason I made these changes is because this is a large board which resulted in noise pickup issues on the on the very long nRESET trace when it was just "floating high". My plan was to solve that by actively driving it high instead. I also wanted to add a feature where I could use one of the MCU's GPIO pins to trigger a full board (not just MCU) reset programmatically by pulling the nRESET signal low.

The changes seem to have fixed the two problems I had but have now introduced a new problem where I cannot program the board easily with an ST-Link (V3 MINIE) anymore. I normally use probe-rs for programming, but have verified that the official STM32CubeProgrammer shows very similar issues.

When I try to program with "connect under reset", then it seems that the ST-Link almost never drives its nRESET output low and thus programming fails unless I manually drive the signal low at the correct time by pressing the physical reset button which is connected to the same net. Nothing on this net can force the signal high so this cannot be a result of contention, it has to be that the ST-Link is not even trying to pull the signal low for some reason.

Another problem I now have is that after I manage to get it programmed, the MCU now halts (possibly because of a crash but I am not sure) until I either manually get the debugger to resume execution or if I detach the debugger. Physically pressing reset while the debugger is still attached is not enough to make it run, but repowering the board without the debugger attached is enough. This is strange because I am not telling the debugger to halt the MCU after programming and my previous board did not have this issue. STM32CubeProgrammer reports this as "Warning: The core is halted" after programming finishes whereas probe-rs makes it look like a crash of sorts.

My question is whether there are "hidden" requirements on the nRESET pin of the MCU that can explain all this strange behavior. Specifically, is there something that can go wrong when nRESET is being actively driven high rather than pulled high? Perhaps the MCU itself needs to be able to pull this signal low under certain conditions?

GerhardLnf · ‎2025-08-08

I have now removed the buffer (U2) and this seems to have solved the issue. It seems that the STM32 does indeed need to (very momentarily) pull its own nRESET pin low at certain times during programming to reset properly.

Probe-rs still does not work with "connect under reset" for some reason even though STM32CubeProgrammer now works perfectly. I'm not really sure what the issue there could be though since it worked fine with the old board. At this point the only remaining difference is that the ST-Link cannot see when the STM32 pulls its own nRESET pin low and the reset pulse from the ST-Link gets slightly stretched.

P.S. I also switched to a reset controller IC with a much shorter delay since the one I originally chose likely stretched the reset pulse from the ST-Link too much. But I am not sure if this was strictly needed.

View solution in original post

GerhardLnf · ‎2025-08-08

I have now removed the buffer (U2) and this seems to have solved the issue. It seems that the STM32 does indeed need to (very momentarily) pull its own nRESET pin low at certain times during programming to reset properly.

Probe-rs still does not work with "connect under reset" for some reason even though STM32CubeProgrammer now works perfectly. I'm not really sure what the issue there could be though since it worked fine with the old board. At this point the only remaining difference is that the ST-Link cannot see when the STM32 pulls its own nRESET pin low and the reset pulse from the ST-Link gets slightly stretched.

P.S. I also switched to a reset controller IC with a much shorter delay since the one I originally chose likely stretched the reset pulse from the ST-Link too much. But I am not sure if this was strictly needed.

Tesla DeLorean · ‎2025-08-08

In fact most ARM designs dating back 20 years, expect NRESET to be open-drain, not an external PUSH-PULL driver. That sort of thing prevents the NVIC_SystemReset() and internal watchdog peripherals from working, ST also has it's own POR circuit off the VDDA supply. And often results in undefined startup operation of the MCU, as it can't reset properly.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Andrew Neil · ‎2025-08-08

@GerhardLnf wrote:
It seems that the STM32 does indeed need to (very momentarily) pull its own nRESET pin low at certain times

Indeed, the STM32 does also drive NRST as an output:

https://www.st.com/resource/en/reference_manual/rm0090-stm32f405415-stm32f407417-stm32f427437-and-stm32f429439-advanced-armbased-32bit-mcus-stmicroelectronics.pdf#page=153

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

GerhardLnf · ‎2025-08-10

@Tesla DeLorean @Andrew Neil thanks! Yeah, I blindly just assumed that nRST is an input only pin and that the "real" reset signal would be hidden inside the MCU. Based on STM32G0-System-Reset-and-clock-control-RCC.pdf, it seems the STM32G0 at least has a mode where it can work like that if desired.