STM32F446 Nucleo won't boot on external power

[MBald.1]

I have a project, using a Nucleo board, the software runs fine when powered by the USB cable, but when I use an external 12v PSU connected to the external input, on power-up, it does not start. Pressing the reset button makes everything start as expected. Unfortunately, I do not have an oscilloscope to look at the power-line as it is starting. I have tried an external power monitor to reset the card, but this did not work either, I am happy that this external monitor was working as removing it's power & re-applying caused the expected reset.

Other than changing the link for the power from USB to external, I have not changed anything else on the Nucelo board.

Has anyone got any suggestions as to what I have missed?

[Piranha]

https://community.st.com/s/question/0D53W00001t46n6SAA/stm32f767zi-on-external-power-supply-is-stuck-until-reset-button-is-pressed

[MBald.1]

Thanks for that, my search didn't find that, I have no idea why.

[MBald.1]

Having read that, although it is for a different board, it seems I will need to remove the reset from the ST-Link by removing SB12, in the manual for this board, this is only mentioned when powering from an external 3.3v supply, does that sound correct?

Am I correct in thinking that if this reset link is removed, that then I can still programme via the USB connector, but will need to manually reset to run the code? If not, I assume I will have to get everything right then remove the link or keep adding/removing the link.

[Tesla DeLorean]

Different versions of the ST-LINK firmware behave differently.

Generally you need to disconnect NRST so it doesn't hold the part in reset.

If you need to do it a lot wire in a jumper.

The "Connect under Reset" will not work from the programming tools, although there are typically multiple modes of connectivity, and you mainly need the mode if the code on your board puts the STM32F4 into a low power or sleep mode, or reconfigures the PA13/PA14 pins involved with the debugger.

[MBald.1]

I have removed SB12, NRST, unfortunately this has not resolved the issue. I have questioned if this would be the reason as if this was holding the STM32F4 in reset, then upon releasing the reset button I would have assumed that the STM32F4 would still not run.

I think I will have to get to the position that I can connect the debugger once powered by the external supply so I can see where it is in code, in case it is stuck in a loop in an error handler. Unfortunately this code was not originally written using the CubeIDE, and does not have the "normal" error handler I was hoping to find.

If there are any other thoughts on what I could do, I am open to suggestions.

[MBald.1]

It has got even stranger, trying to debug what was happening hasn't worked, I powered the Nucleo connected to my PCB & PSU, then plugged in the USB as per the details in the documentation, immediately that the USB was connected, everything ran as normal. I took the Nucleo off my PCB, confirmed that the NRST solder bridge did not have a whisker of solder across it, there wasn't any, so cannot see how powering the Nucleo via USB could cause this issue.

I programmed the board with a really simple programme to just flash the on-board LED, that all worked regardless of how it was powered. There must be some issue with what my programme does rather than an issue of how it is powered, so I consider this case closed.

[henrique]

As a Update, I had the same issue.

For me, setting the ord to use internal high speed clock solved the problem.

It's possible that when powering the board with external source, the ST-Link can't output a stable clock source, before clock configuration on STM32F4 chip. So it enters in a fault state.

[Bearded_PCB]

I ran into this also. I found that the MB1136 Nucleo Board receives its clock signal from the ST-LINK programmer along MCO. When using external power on VIN (12V), the MCO line requires 3s before the clock settles enough to run the micro on the Nucleo.

If you place a HAL_Delay(3000) ; after the HAL_Init(); everything works fine. If you need a faster start adding an oscillator in X3 would be required.