Why is USE_PWR_LDO_SUPPLY defined by default when generating a project in CUBEMX?

[Peter3718]

Hi there, 

i configure power as PWR_DIRECT_SMPS_SUPPLY, 

but after generating project,  both PWR_USE_LDO_SUPPLY and PWR_DIRECT_SMPS_SUPPLY are defined. This will cause program exception sometime, i have to remove USE_PWR_LDO_SUPPLY.  I took several days to locate this issue!

so my question is:

1. Why is USE_PWR_LDO_SUPPLY always defined by default?

2. Where are these preprocessors comming from? so I can configure.

Best regards

Peter

[Tesla DeLorean]

>>Why is USE_PWR_LDO_SUPPLY always defined by default?

Probably because a significant majority of ST boards, be it DISCO, EVAL and NUCLEO use the LDO

There are a handleful of -Q / -P boards/chips using the SMPS mode.

Some chips run at derated speeds with SMPS

So, I'd expect the defaults here are driven by part or board selection earlier in the process.

From your post it's not clear what board/chip you are bug reporting.

[Peter3718]

I use STM32H755ZIT6,  if generating from ST board NUCLEO-H755ZI-Q in CUBEMX, it has no this preprosssor. If generating from chip level, even has no any IO setting, the two predefined marco are there. You can try this, it's really tricky!  I want to know where it is from.

Peter

[Peter3718]

i was using code comparison,  and no any clue found. Finally, i found the difference in complier setup inside of IDE.

The consequence is board will never boot up, and ST-LINK can not find target.  You have to set to boot from system memory to recover the board.  This is typical consequence of wrong power scheme. Some guys may ran into this issue in this community, but no one tell the clear answer.

Peter

[Amel NASRI]

Hi @Peter3718 ,

Thanks for bringing this issue to our attention. I tracked it internally (199456) for farther investigation by our development team, looking forward for a quick fix.

A similar problem is being discussed here.

-Amel

[Tesla DeLorean]

"The consequence is board will never boot up, and ST-LINK can not find target. You have to set to boot from system memory to recover the board. This is typical consequence of wrong power scheme. Some guys may ran into this issue in this community, but no one tell the clear answer."

Yes, I'm aware of the LDO vs SMPS lockout issues, dating back to 2017/2018 as I recall

https://community.st.com/t5/stm32cubeprogrammer-mcus/stm32h747-discovery-kit-not-debug-programmer/m-p/237335

https://community.st.com/t5/stm32cubeprogrammer-mcus/error-to-connect-to-target-stm32h747i-disco/m-p/294136

Probably find ones covering adding a BOOT0/VDD jumper on the side of a NUCLEO-144 board

https://community.st.com/t5/stm32cubeprogrammer-mcus/not-able-to-connect-to-nucleo-h755zi-q/td-p/198778

How Cube manages this, and self-conflicting settings and options is another matter.

[Amel NASRI]

Hi @Tesla DeLorean & @Peter3718 ,

We tried to answer this known issue via several knowledge articles:

• Unable to connect to STM32H7 devices
• How can I recover my STM32H7 board after facing a power configuration deadlock?
• How to unbrick an STM32H7 after setting the wrong power mode

-Amel

[Peter3718]

Hi, @Amel NASRI @Tesla DeLorean 

The above are not problems, this is routing step for MCU lockout. This is not stress of my post. I am asking why Both USE_PWR_LDO_SUPPLY and USE_PWR_DIRECT_SMPS_SUPPLY are defined during code generation. This will cause MCU lockout after power cycle.

Regards

Peter

[Amel NASRI]

This later (Both USE_PWR_LDO_SUPPLY and USE_PWR_DIRECT_SMPS_SUPPLY are defined as preprocessors) is the confirmed issue that I tracked internally with the ID 199456.

I checked that there is no such issue when generating EWARM project.

-Amel

[Peter3718]

Hi, @Amel NASRI 

By the way, RCC clock auto configuration is also wrong.

but result showing:

which will mess up UART baud rate ( I have to chage UART clock source to HSI to get correct UART output, the old is PCLK1), same issue as the post you linked.

CubeMX 6.13.0 and MCU Package H7 v1.12.0 produce i... - STMicroelectronics Community

These issues are fundamental, need to be resloved with high priority.

Peter