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.

[Amel NASRI]

Hi @Thibault SÉNAC​  & TDK,

I agree with you that this should be a limitation with STM32CubeMX generated code.

Our STM32CubeMX Experts (@Nawres GHARBI​ , @Khouloud ZEMMELI​ ) can confirm this and take relevant actions to fix it.

-Amel

[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

[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.

[Khouloud ZEMMELI · Accepted solution]

Hello @Thibault SÉNAC​ ,

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

Khouloud

[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