Possible error in USBD_conf.c produced by cubemx (with solution provided)
I have been chasing a very intermitant issue with some STM32L100 based products.
The problem shows itself with the MCU being reset by the WDT part way through the initialisation sequence.
This issue only displays itself when the MCU has reset itself using NVIC_SystemReset();
E.G. the program flow is as follows
Running program
NVIC_SystemReset(); is called
MCU resets and goes through the init section in main.c
part way through the init section, it locks up and the wdt resets the mcu.
Once it has started to do this, it can stay in this reboot loop until you re-power the MCU OR it can recover after only one reboot. There is no pattern to how it recovers without a power cycle
This does not happen when you power up the mcu, it only happens when the mcu has been reset using NVIC_SystemReset();
Plugging in a USB cable into the board and a pc stops the reboot cycle. (no app on the pc needs to be using the usb com port)
We have several thousand products in the field and we come across this issue once every three to four months, so it has been very difficult to reproduce and fix.
The problem was found to be a race condition between the USBD_Start() function being called and the usb interrupt being raised. If the usb interrupt was raised before USBD_Start() had completed, you would enter a continual interrupt loop and stay there until the mcu was reset.
The solution involved the following
1: Remove the line of code in HAL_PCD_MspInit() that enabled the USB interrupt
2: In the function MX_USB_DEVICE_Init(), after the USBD_Start() function has been called, clear any pending interrupts and then enable the interrupts using the following lines.
NVIC_ClearPendingIRQ(USB_LP_IRQn);
NVIC_EnableIRQ(USB_LP_IRQn);
We have the same code running on STM32G0 mcu’s and we have not seen this issue with them (yet).
As this code is auto generate in this way by CubeMx, can this change be introduced into its code base for fuiture releases.
Thanks