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.

[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!

[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"...

[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.

[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]

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]

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