Possible stm32G0 cube mx generation Error for usb

[TSÉNA.1]

While setting up a project using cubeMx for a stm32G0, I stumbled across a possible error on the USB_device files. This error resulted in the usb reset handler stalling the machine. My project specifies the USB as full speed and looking in the generated usbd_conf.c, I found the following lines in HAL_PCD_ResetCallback

USBD_SpeedTypeDef speed = USBD_SPEED_FULL;
 if (( hpcd->Init.speed != USB_DRD_SPEED_FS) || (hpcd->Init.speed != USB_DRD_SPEED_LS))
 {
 Error_Handler();
 }
 /* Set Speed. */
 USBD_LL_SetSpeed((USBD_HandleTypeDef*)hpcd->pData, speed);
 
 /* Reset Device. */
 USBD_LL_Reset((USBD_HandleTypeDef*)hpcd->pData);

In that case the line 2 test will always result in the Error_handler being called as we are indeed FS (and thus not LS). Using thins condition instead solved the usb issue :

if( hpcd->Init.speed != USB_DRD_SPEED_FS){
 Error_Handler();
}

Could this be an oversight in the cubeMX generation or is it that I missed something blatantly obvious ?

[TDK]

It's clearly a bug. That statement is always true. Should be && instead of ||.

I can't find that line anywhere within the STM32CubeG0 repository. Their examples don't have the issue. Are you on the latest repo verson?

https://github.com/STMicroelectronics/STM32CubeG0/search?q=USB_DRD_SPEED_LS

[TSÉNA.1]

That confirms my analysis !

I just checked and my repository folder does contain the 1.4.1 version. Something must have gone wrong in the generation. I do not rule out a mistake from my part though, I just wanted to be sure I was not missing something, thanks TDK !

[TDK]

It could still be a bug introduced during code generation. I didn't check.

[Khouloud ZEMMELI]

Hello @Thibault SÉNAC​ ,

Thanks for raising the point,

This will be internally checked.

Khouloud

[Khouloud ZEMMELI]

Hi again @Thibault SÉNAC​ ,

Yes, it's confirmed and issue will be fixed, thank you for bringing this problem to our attention, also thank you @TDK​ for the workaround proposed :)

The fix will be as following :

if (hpcd->Init.speed != USBD_FS_SPEED)
 {
 Error_Handler();
 }

Khouloud

[Khouloud ZEMMELI]

Hello @Thibault SÉNAC​ ,

Issue has been fixed in the latest CubeMX version (6.3.0) available on site :)

Khouloud

[Fluxon]

Hi @Khouloud ZEMMELI​,

I was having the same issue, but I also found the bootloader of the STM32G0B1xx doesn't work with USB DFU mode.

Could it be related to the same error which also might be present in the code of the bootloader?

Specifically, with the above-mentioned correction, I am able to get USB DFU working in user flash, however, the device is not recognized when connected in bootloader mode.

[MichaelSweden]

I'm using a STM32G0B1CCU6 device and factory bootloader works fine with USB (DFU mode). At first power on it appear as a DFU device on USB. Since the flash was empty, the bootloader was started. After programming and power off/on, my application was executed.

$ dfu-util -d 0483:df11 -c 1 -i 0 -a 0 -s 0x08000000 -D MyAppl.bin

I can also jump to the bootloader, instead of starting main() in my application. Have modified SystemInit() in the system_stm32g0xx.c file to be able to do this.

To start bootloader by set BOOT0 pin high, didn't work. However after reading manual I realize that it is disable by default. This can be activated by configure option bytes. Need to set nBOOT_SEL to zero (nBOOT=1 and BOOT_LOCK=0, as default). By use of ST-LINK V2 I changed nBOOT_SEL and got wanted functionality. BOOT0pin: low=Application high=BootLoader

$ STM32_Programmer.sh -c port=SWD mode=UR --optionbytes nBOOT_SEL=0

So my conclusion is that the bootloader works fine with USB, at least in STM32G0B1CCU6.

PS. I notice the power consumption is high, 0.17A. While my application is running it is below 0.007A.

//Michael

[Banxian]

I am using stm32cubemx 6.4.0 with the fixed version of HAL_PCD_ResetCallback, but still can't get usb device to work.

I created template project by cubemx, and selected usb cdc device from middleware and enabled usb in connectivity. I also enabled swd for debug.

I solved clock in wizard, hclk is clocked from hsi16->pll, and usb clock is hsi48.

after rebuild and download, device triggered a enumeration but doesn't reply to host.

I am using a beagle usb sniffer, it doesn't reply first setup packet(get descriptor).

the dfu bootloader works fine if I erased flash, so it's not a hardware problem I think.

​

edit:

I changed some extra options in ​cubemx, if I enable CRS sync in RCC settings and usb interrupts in NVIC settings, usb device can be recognized by host now.

[MichaelSweden]

Oh, now you find it. I was on the way to write this:

I have not used that version, but maybe I anyway can recommend to check that the "USB, UCPD1 and UCPD2 global interrupts" is enabled, (System Core - NVIC).