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 not so clear what you want to do, or say, your use case is not clear.

- if you want to run your code in standalone mode, you may just put on-board ST-LINK in RESET state.

- if you want to run your code in debug mode, you just need to connect your IDE with on-board ST-LINK

- some time ago, I had a problem similar to yours. I had some nucleo boards with different STM32, program-and-run (with same version of cubeprogrammer) OK for some STM32 but not OK for others. there was a tip to solve such issue.

[ricks]

Dear Jiangfan,

I don't know what is not clear.  The daughter board with the ST- Link is always attached and we need the serial com of it for serial communications as part of our application.  Everything boots and runs fine when the entire Nucleo is powered via USB.  When we move the jumpers to run on VIN EXT, the Nucleo does not get through the boot process.

Hitting the RESET SW after the boot fails, does get the the system up and running, but we don't want our customer to do that and he should not have to.

You said you had a similar problem and there was a tip to solve the solution.  What was the tip?  Please explain in detail.  Thanks!

[ricks]

Hello all we have an update!

My business partner working on this project found a solution to this issue.  All of my projects are now having an issue with the SystemClock_Config routine that is generated by the IDE.  Specifically, it fails the HAL_RCC_OscConfig call when powered by the external power. I believe this is connected to the Clock PLL when using a higher operating frequency.   His fix is to put a substantial delay (3 seconds) prior to calling the clock config routine. This is allowing the PLL to stabilize.  This was not required in prior versions of the IDE and/or ST Link.

[ricks]

Corrected Version:

Hello all we have an update!

My business partner working on this project found a solution to this issue.  All of our projects are now having an issue with the SystemClock_Config routine that is generated by the IDE.  Specifically, it fails the HAL_RCC_OscConfig call when powered by the external power. I believe this is connected to the Clock PLL when using a higher operating frequency.   His fix is to put a substantial delay (3 seconds) prior to calling the clock config routine. This is allowing the PLL to stabilize.  This was not required in prior versions of the IDE and/or ST Link.

[jiangfan]

my case is similar to yours, but not the same. My nucleo boards were powered by on board ST-LINK USB port.

[jiangfan]

good to see that you found a workaround to solve the issue.