Nucleo ST32F4F439ZI will not run on VIN External Power

[ricks]

We have a very time-sensitive project that uses the Nucleo ST32F439ZI Development Board.

It works, boots, and emulates just fine when powered from USB however, when externally powered it gets stuck and will not boot properly or work with the USB ST-Link debug without and additional manual reset.  It turns out that the are others who have expressed similar issues as shown in the links below:

https://community.st.com/t5/stm32-mcus-products/stm32l432-nucleo-32-external-power/m-p/332038

https://community.st.com/t5/stm32-mcus-products/stm32l432-nucleo-32-external-power/td-p/332038/page/2

Everything works as expected with a new board out of the box running the factory pre-programmed blink routine using EXT Vin to power the board.  When we use the latest CUBE IDE to develop and debug, it requires an update to the ST-Link version.  After installing the latest ST-Link version, the board will no longer run with Vin (external) power.  It does start running once you connect the ST-Link to USB.  It will run after a reset or just reconfiguring to USB 5V power (no external Vin).

We have tried all of the suggestions on the forum and had no success.

[jiangfan]

It is recommended to put in RESET state (short SB107) for the on-board ST-LINK to avoid its negative impact. this should be the easiest way to solve the issue.

[jiangfan]

In case further debugging with on-board ST-LINK is still needed, it is deserved to solder a small jumper in place of SB107 and short the jumper when needed.

[ricks]

Thanks Jiangfan, but that did not work and made things worse.  It makes sense too because that SB107 jumper holds the U2 processor in permanent reset.  There has to be something else going on.

[Piranha]

https://community.st.com/t5/stm32-mcus-boards-and-hardware/stm32f767zi-on-external-power-supply-is-stuck-until-reset-button/m-p/115194

[ricks]

We have looked at those posts and tried them and nothing has worked!

[Piranha]

Sounds like you don't want to solve the problem... Otherwise you would tell what exactly you did and what exactly didn't work.

P.S. My post in that topic doesn't even provide a "solution", it just shows and explains the problem. So there was nothing to "try"...

[Tesla DeLorean]

Are you sure it's not executing your code, and not stuck somewhere? Perhaps have code in Reset_Handler toggle a GPIO, or output to a UART. Run the MCU from the HSI, don't try to start the HSE or PLL. Instrument while(1) loops in Error_Handler() and HardFault_Handler() so it doesn't quietly die in those.

Unfortunately "Tried Everything" doesn't really convey what you did, nor the observations when you did them. It's hard to check off a list here to suggest something you haven't tried.

[ricks]

We thought that might be the case, so we started a new project that simply blinked the on-board LED1 and had same result.  When the problem occurs it doesn't even reach the HAL initialization routines.  All of this worked before and we have tried several Nucleo boards.  We will try some of your suggestions.  When we say we tried everything, we mean that we tried virtually all of the suggestions we saw in the forum.

[ricks]

Our project worked for a few months without this issue.  We thought it might be something in our more recent code changes, so we started and tested a new bare-bones project using the ST default board target configuration file with our added code that simply blinked the on-board LED1, and we got same result.  It is hard to say when this stopped working.  It seemed to happen after one of the upgrades of ST-Link and Cube IDE, but we can't be sure.