2020-09-04 09:08 AM
Hi,
I'm using CubeIDE 1.4.2 with CubeMX 6.0.1-RC3 and target is STM32L452.
This problem only occured with VDDUSB independent from VDD.
I had problems with USB FS device initialization (using CDC class but I guess it applies to other classes as well).
The problem was that after boot, when calling MX_USB_DEVICE_Init() with VDDUSB not present (usb not plugged in), the program was endlessly interrupted and stuck in USB_IRQHandler(), after calling USB_DevInit() in HAL_PCD_Init() in the file stm32l4xx_hal_pcd.c.
The problem never occured when VDDUSB was present (usb plugged in).
Here's the call hierachy :
Reading the Reference Manual RM0394, it's mentioned page 137 :
As specified in the title, MX_USB_DEVICE_Init() never follows this sequence before removing the power isolation by setting the USV bit in PWR_CR2 by calling HAL_PWREx_EnableVddUSB(). The PVMO1 bit is never checked, which surely caused problems in further USBD initialization.
Call hierachy :
Checking if VDDUSB is present before calling MX_USB_DEVICE_Init() solved the thing.
Hope it can help someone.
(and maybe the check could be added in next version of CubeMX FW_L4 Package?
I'm using V1.15.1 here but I checked and it's still the same in V1.16.0)
Regards,
OE
2020-10-19 08:12 AM
Hello @OE
Thank your for your post. We need a step by step scenario to be able to understand and reproduce your issue.
Can you please give us the exact scenario and the ioc file or the all zipped project to try reproduce what you are seeing?
Best regards,
Nesrine
2020-10-19 09:19 AM
Hi, thanks for the reply,
I detailed (maybe too much) everything in the original post, but I'll try to be clearer and more concise here (though I thought the title was summing it up quite efficiently)...
The problem's symptoms :
The problem's source :
The question : was this check omitted intentionally by the team managing MX generated code? :
Regards,
OE