Missing bootloader command

[Elmue]

The AN3156 explains on page 18 the Read Unprotect Command:

This command is selected when wValue = 0 and the first byte of the buffer sent by the host
is 0x92. The buffer length is only one (the command) byte.
The host sends a DFU_DNLOAD request with the above parameters to remove the read
protection of the internal flash memory.

 

It is very useful that you implemented a command to remove the read protection.
But this is useless if there is also a write protection active.
The user has no way to remove a write protection over the DFU protocol.

Why does this command not remove both: The read protection AND the write protection at the same time?
Why does STM implement nothing that allows to remove a write protection ?

[FBL]

Hi ​@Elmue  @STOne-32 

Some comments have not been migrated to the new platform. 

An internal ticket is submitted to dedicated team to clarify scope of this read unprotect command. For internal reference CDM0062909 

[Elmue]

What do you mean with “new platform” ?

[Bob S]

ST recently switched to new forums software (i.e. “platform”)

[Elmue]

What is the new URL ?

[Chris21]

URL is the same, you are now using the new platform.

[FBL]

Hi ​@Elmue  

Coming back to this topic with the clarification from our internal team :

• Read protection RDP and write protection WRP are two distinct hardware features.
• The Read Unprotect command only performs an RDP regression.
• By design, RDP reset does not clear WRP.
• So if write protection is also enabled, it must be removed separately.

This behavior is normal and consistent with the other bootloader interfaces as well:

• On USART / I2C, the same rule applies:  RDP reset does not clear WRP.
• The key difference is that some protocols provide a Write Unprotect command, while the current bootloader implementation for USB DFU does not.

For USB DFU, clearing write protection requires option byte modification. So, the current implementation follows the intended hardware behavior.

[Elmue]

You are telling me absolutely nothing new.

You only confirm what I rote in the first posting.

This implementation lacks any intelligence.
You provide a DFU command to remove read protection.

But if write protection is enabled there is NO DFU command to remove it.

So you cannot program the processor over DFU.

Why do you implement a command to remove read protection and there is no command to remove write protection?

 

You needed 3 months to only confirm what I already knew before.
This is a completely useless forum.

 

[TDK]

​@Elmue To change option byte settings, use the Write Memory command, as described in AN3156. This is available in the USB DFU bootloader.

This will cause a system reset to apply the new option bytes:

The option byte registers/fields are given in the reference manual.

 

You should use Read Memory command to get current settings, change the write protection field, and then Write Memory to write the new value with the other fields unchanged.

[Elmue]

> To change option byte settings, use the Write Memory command,

Your answer is useless.
I’am here with STM32G0B1

It does NOT allow to modify any option byte over DFU.

It only exposes ONE USB interface to read / write the 128k flash memory.

If you have a STM32G0B1 with Read and Write protection enabled there IS NO WAY to program this processor over USB.

This processor is STUPIDLY designed,

 

[TDK]

It does NOT allow to modify any option byte over DFU.

It only exposes ONE USB interface to read / write the 128k flash memory.

What makes you say that? What happens when you try?

Why would there be a separate USB interface for option bytes? There is one bootloader, it uses the same interface for all commands.

[Elmue]

I see that you have never sent a DFU command in your life.

Show me the bytes that you would send over USB that would modify the option bytes of a STM32G0B1 processor to reset the write protection!

 

Which DFU command would you use ?
Which parameters would you send ?

 

 

[TDK]

I see that you have never sent a DFU command in your life.

Brother, you are making this harder for those helping with all the unnecessary talking down and snark.

The actual bytes in the commands to send are outlined in AN3156. Typically, you are not interfacing with the bootloader at the byte level in DFU so these are not helpful. How you send them depends on what software you are using to interface with USB DFU. What software are you using? In STM32CubeProgrammer, you would change the address to show option bytes, edit one, and press enter.

Here’s it being done on the STM32H7. Hold BOOT0, connect over USB DFU. Same plan for the G0x1, likely different addresses.

You can see the WRP value is 0xF0. Change it to 0xFF, hit enter. Value has changed.

Power cycle it. Value has still changed. All through USB DFU interface. All through supported commands.

Can also be done with the CLI if you want.

Why does this command not remove both: The read protection AND the write protection at the same time?

Because WRP and RDP are different and RDP unprotect was not designed to modify WRP.

Why does STM implement nothing that allows to remove a write protection ?

They do, as shown in the screenshot.