Skip to main content
Associate II
May 19, 2026
Question

Bif fat ugly bug in STM32G0B1 bootloader

  • May 19, 2026
  • 2 replies
  • 165 views

The STM32G0B1 has a very ugly bug in the bootloader.

When I have a write protection on a flash memory area:

WRP1A_STRT = 0x0 --> 0x08000000
WRP1A_END = 0x1 --> 0x08000800

and then I upload a new firmware to this area the firmware will not be written, because this area is write protected.
This is correct.

But it is a horrible bug that I send a USB control request with

Request.Function=URB_FUNCTION_CLASS_INTERFACE;
Request.Direction=VENDOR_DIRECTION_IN;
Request.Request=DFU_GETSTATUS;
Request.Value=0;
Request.Index=0;
Request.Length=6;
Result = STDevice_ControlPipeRequest(hDevice, &Request, (BYTE*)pkDfuStatus);

and the buggy bootloader returns STATUS_OK (value 0) instead of STATUS_ErrorWRITE (value 3)

The user thinks that the firmware was uploaded correctly but the processor is dead because the flash memory is corrupt.

 

2 replies

ST Technical Moderator
June 17, 2026

Hi ​@Elmue 

It seems the content has not been migrated to the new community.

Regarding, DfuStatus_ErrWrite as usual if memory cannot be written. Instead they use their own error code.
 

Image1.png

As you can easily see here even the official ST documentation states that in case that a protected memory cannot be written the processor should return error Status = ErrVendor and State = dfuError.

 

My answer : In my understanding, the protection mechanism involved here may relate to read protection rather than write protection.

An internal ticket CDM0062911 is submitted to the dedicated team for further investigation and clarification.

To give better visibility on the answered topics, please click on "Best answer" on the reply which solved your issue or answered your question.Best regards,FBL
ElmueAuthor
Associate II
June 18, 2026

Yes, instead of using DfuStatus_ErrWrite  they use their own Status = ErrVendor and State = dfuError  which is not a good idea because it is less specific.

But this does not work.
The bootloader returns STATUS_OK  which is totally wrong.

> the protection mechanism involved here may relate to read protection rather than write protection.

I don’t understand what you mean with “involved here” ?

Obviously the processor should return an error when writing and writing is not allowed.
And it should return an error when reading and reading is not allowed.