cancel
Showing results for 
Search instead for 
Did you mean: 

USB VDD issue

Kaushik1
Associate III
We are using the STM32H7R7L8H6H microcontroller in our product design.
During firmware initialization, we observed inconsistent behavior related to the USB voltage detector on different boards that share the same hardware design and firmware.
Specifically, the following code auto generated by STM32Cube ide (stm32h7rsxx_hal_msp.c), this causes the MCU to halt on certain boards:
if (HAL_PWREx_EnableUSBVoltageDetector() != HAL_OK)
{  
   Error_Handler();
}
 
On some boards, the code runs normally, but on others, it enters Error_Handler() immediately after executing this function.
Both boards have identical hardware configuration — USB is not used, and VDD33USB and VDD50USB are tied to 3.3 V.
- Advise whether disabling the USB voltage detector is the recommended workaround when USB is not used.
- Provide any official ST guidance or firmware-level / Hardware level workaround for this behaviour.
USBVDD.png

Should we modify the voltage level on the VDDUSB pin, or adjust the mounting status of the 0-ohm resistor instead? please see attached image.
- Should we comment above line permanently, in that case this lines will auto generated when moodifying .ioc file.
@Mehulrana511 

Edited to apply source code formatting - please see How to insert source code for future reference.

5 REPLIES 5
TDK
Super User

This shouldn't even compile. HAL_PWREx_EnableUSBVoltageDetector does not return a type.

stm32h7xx-hal-driver/Src/stm32h7xx_hal_pwr_ex.c at d649ed2c7784bfbef4be144e7bfd8dbb41dce5c3 · STMicroelectronics/stm32h7xx-hal-driver

 

If CubeMX is generating this, it's a bug in CubeMX. Please attach your IOC file.

If you feel a post has answered your question, please click "Accept as Solution".
FBL
ST Employee

Hi @Kaushik1 

Would you increase the PWR_FLAG_SETTING_DELAY : e.g. multiply it by 10 to see if the issue persists?

For STM32H7RS, when USB is not used, you can connect VDD33USB to 0 V to minimize any possible leakage. Also, USB33DEN should be set if a GPIO on port M is used.

It is mentioned in this knowledge base article.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.



@TDK wrote:

This shouldn't even compile. HAL_PWREx_EnableUSBVoltageDetector does not return a type.


But, in an expression, the function still has a value - which is its address.

So it should compile - but it won't do what's intended!

 


@TDK wrote:

If CubeMX is generating this, it's a bug in CubeMX. 


Agreed!

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

A void function does not return a value and cannot be used in an expression.

Its value is not its address--that's nonsense.

TDK_0-1762445792873.png

 

If you feel a post has answered your question, please click "Accept as Solution".

@TDK wrote:

Its value is not its address--that's nonsense.


You're right - that only applies without the parentheses.

 

So the code @Kaushik1 presented can't be the real code

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.