Bif fat ugly bug in STM32G0B1 bootloader

[Elmue]

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.

[FBL]

Hi @Elmue 

DFU_GETSTATUS returns the status of the DFU protocol state machine, not the success/failure of the last flash programming operation. 

[Elmue]

> DFU_GETSTATUS returns the status of the DFU protocol state machine,
>not the success/failure of the last flash programming operation.

You are totally wrong !

Did you ever study the states of the DFU protocol ???

DfuStatus_OK = 0, // No error condition is present.
DfuStatus_ErrTarget, // File is not targeted for use by this device.
DfuStatus_ErrFile, // File is for this device but fails some vendor-specific verification test.
DfuStatus_ErrWrite, // Device is unable to write memory.
DfuStatus_ErrErase, // Memory erase function failed.
DfuStatus_ErrCheckErased, // Memory erase check failed.
DfuStatus_ErrProg, // Program memory function failed.
DfuStatus_ErrVerify, // Programmed memory failed verification.
DfuStatus_ErrAddress, // Cannot program memory due to received address that is out of range.
DfuStatus_ErrNotDone, // Received DFU_DNLOAD with wLength = 0, but device does not think it has all of the data yet.
DfuStatus_ErrFirmware, // Device’s firmware is corrupt. It cannot return to run-time (non-DFU) operations.
DfuStatus_ErrVendor, // StringIdx indicates a vendor-specific error.
DfuStatus_ErrUSBR, // Device detected unexpected USB reset signaling.
DfuStatus_ErrPOR, // Device detected unexpected power on reset.
DfuStatus_ErrUnknown, // Something went wrong, but the device does not know what it was.
DfuStatus_ErrStallEP, // Device stalled an unexpected request.

As you can easily see there is a DFU Status for each type of error:
Write errors, Read Errors and Erase errors.

It is a big fat bug to return OK if the memory could not be written !
The correct response should be DfuStatus_ErrWrite.

What a useless enumeration would this be if your assumption would be correct!

[Elmue]

STM does not always comply with the DFU specification and creates their own procedures.
STM states that they do not use DfuStatus_ErrWrite as usual if memory cannot be written.
Instead they use their own error code.

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.

But it does not.

So this is DEFINITELY a HUGE BUG !

FBL wrote:
> DFU_GETSTATUS returns the status of the DFU protocol state machine,
> not the success/failure of the last flash programming operation.

This is a complete nonsese.
Once again I see in this forum that people who are flagged as "ST Emplyee" like FBL did not even read the documentation of their own company.
This is really a SHAME !
This forum is once more completely useless and a waste of my time..

[FBL]

@Elmue, I understand your frustration.

In my understanding, the protection mechanism involved here may relate to read protection rather than write protection. To avoid any ambiguity, I have submitted an internal ticket CDM0062911 to the dedicated team for further investigation and clarification.