Bootloader (USB) DFU Issues on the new STM32G0B1xx

[Fluxon]

I had a previous issue with the generated CubeMX code, but saw it was already found in:

https://community.st.com/s/question/0D53W00000qwRCQSA2/possible-stm32g0-cube-mx-generation-error-for-usb

As per this fix, I am able to get USB DFU working in user flash. However, once connected in bootloader mode the device is not recognized, and in Windows I get a Device Descriptor Request Failed. This is the same error I got without the aforementioned fix in user flash.

PS: As of now I don't expect any hardware issues, as the STM32G0B1 connections are very straightforward, and I was able to get the USB working in user flash.

PPS: Previous issues I found on the community are not relevant to this MCU, as this has all the hardware for USB already built in. The reference manual and datasheet also confirm that the internal clock should be sufficient.

[TDK]

How are you activating bootloader mode?

[Fluxon]

From user flash:

Deinitializing the HAL, resetting the clock configuration, setting syscfg to system flash, setting the msp/psp and finally a function call to the system memory.

[TDK]

Then the error is probably in the way you’re calling it. Don’t call from an interrupt context and ensure interrupts are enabled.
Another method would be to set a magic word in memory, reset, and if the magic word is there, jump to bootloader immediately after reset. For complex projects, this seems like a better option.

[waclawek.jan]

What's wrong with using BOOT0 pin and reset?

JW

[Fluxon]

I also disabled all interrupts, as the code might otherwise be interrupted. I'm running the code from FreeRTOS. I think the code might not be at fault, as I have it working on the the STM32G071 and STM32G474.

I will look into the magic word solution to see if that provides an alternative, thank you for the suggestion.

By the way, I am able to connect to the UART pins using a STLINK Mini v3 and cube programmer. Unfortunately it seems like it is only the USB which does not respond.

@Community member​ 

In this specific project we are using the 32 pin version, without spare pins left. (As these were the only ones available due to the chip shortages). Besides, the STM32G0B1xx offers the super useful feature of only needing a USB cable to program it in DFU mode. Which requires no hardware interactions/ interruptions.

[TDK]

> I also disabled all interrupts

> ...only needing a USB cable to program it in DFU mode. Which requires no hardware interactions/ interruptions.

I'm fairly certain the DFU bootloader requires interrupts to be enabled and that the UART does not. This is not documented but there are other threads like this that lead me to believe it. Regardless, things should be in a reset state (PRIMASK=0) before calling the bootloader.

Here are two such threads, but there are others:

https://community.st.com/s/question/0D50X0000ADD9vJSQT/stm32l152-no-usb-interface-when-jumping-to-dfu-bootloader

https://community.st.com/s/question/0D50X00009sTgmr/usb-dfu-bootloader-start-from-source

[waclawek.jan]

>In this specific project we are using the 32 pin version, without spare pins left. 

You surely can give up one pin for an experiment, i.e. to find out whether the problem is in software or hardware. Our just use a "known good" board such as Nucleo for experimenting.

JW