0

ST provides a ROM bootloader in the STM32F303RDTx. I am able to jump into the bootloader from my application, and update the flash when read out protection (RDP) is disabled (level 0). When RDP is set to level 1, all attempts to disable RDP (which mass erases the flash) fail. Everything I have tried so far seems to trigger a device reset putting me back into my application.

ST's documentation (AN2606 and AN3155) states that this should be possible, but nothing I've tried works. I have tried ST's GUI demo flasher. I have also tried mass erasing the device and disabling the read out protection via ST's command line client.

The only thing I can think of is that I am jumping into the bootloader rather than using the boot pins to power up into the bootloader. However, even that seems to be something ST has accounted for, as they state that they periodically refresh the watchdog (IWD) in case it has been enabled by calling code.

Attempt to disable readout protection:

C:\Program Files (x86)\STMicroelectronics\Software\Flash Loader Demo>STMFlashLoader.exe -c --pn 6 --br 115200 --db 8 --pr EVEN -i STM32F3_03_02_512K -p --drp
Opening Port                             [OK]
Activating device                                [KO]
Unrecognized device... Please, reset your device then try again
Please, reset your device then press any key to continue

 Press any key to continue ...

Attempt to mass erase:

C:\Program Files (x86)\STMicroelectronics\Software\Flash Loader Demo>STMFlashLoader.exe -c --pn 6 --br 115200 --db 8 --pr EVEN -i STM32F3_03_02_512K -e --all
Opening Port                             [OK]
Activating device                                [KO]
Unrecognized device... Please, reset your device then try again
Please, reset your device then press any key to continue

 Press any key to continue ...

The above commands do execute without error when the readout protection is not enabled.

Attempt to disable readout protection (when it is already disabled):

C:\Program Files (x86)\STMicroelectronics\Software\Flash Loader Demo>STMFlashLoader.exe -c --pn 6 --br 115200 --db 8 --pr EVEN -i STM32F3_03_02_512K -p --drp
Opening Port                             [OK]
Activating device                                [OK]
disabling read protection                                [OK]
reseting device                                  [KO]

As suggested in the comments, I have tried STMCubeProgrammer, with verbosity set to 3 (max). Here are the errors I get:

10:27:43:749 : Serial Port COM6 is successfully opened.
10:27:43:749 : Port configuration: parity = even, baudrate = 115200, data-bit = 8, stop-bit = 1.0, flow-control = off
10:27:43:750 : No Init bits value is : 0
10:27:43:750 : Sending init command:
10:27:43:750 : byte 0x7F sent successfully to target
10:27:43:765 : Wait ends after 1 loop, dataready = 1, delay = 18
10:27:43:765 : Received response from target: 0x43
10:27:43:766 : byte 0x7F sent successfully to target
10:27:43:782 : Wait ends after 1 loop, dataready = 1, delay = 16
10:27:43:783 : Received response from target: 0x6f
10:27:43:783 : Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again...
10:27:43:979 : Disconnected from device.
10:27:44:018 : Serial Port COM6 is successfully opened.
10:27:44:018 : Port configuration: parity = even, baudrate = 115200, data-bit = 8, stop-bit = 1.0, flow-control = off
10:27:44:018 : No Init bits value is : 0
10:27:44:019 : Sending init command:
10:27:44:019 : byte 0x7F sent successfully to target
10:27:45:019 : Wait ends after 1 loop, dataready = 0, delay = 1001
10:27:45:019 : Timeout error occured while waiting for acknowledgement.
10:27:45:020 : No response from target received
10:27:45:020 : byte 0x7F sent successfully to target
10:27:45:120 : Wait ends after 1 loop, dataready = 0, delay = 101
10:27:45:120 : Timeout error occured while waiting for acknowledgement.
10:27:45:121 : No response from target received
10:27:45:121 : Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again...

I have also posted this on ST's Community site here.

Joshua DeWeese
  • 330
  • 1
  • 9
  • I'm not sure for this particular STM32 but for STM32H7 you can change physically the value of BOOT pin to use 2 different boot adresses. by default the second boot adress points to the System bootloader. this allows to unlock a product that has been switched to RDP level 1 if your "regression" code does not work. – Guillaume Petitjean Aug 13 '20 at 12:37
  • Thanks for the tip. The problem isn't getting into the bootloader. The issue is that the bootloader seems to simply refuse to disable flash protection once it has been set. My point about the boot pins was to point out that maybe I am doing something that, while seems supported, is maybe not common. When readout protection is disabled, I can jump into the bootloader and write to the flash without issue though. – Joshua DeWeese Aug 14 '20 at 15:29
  • Did you try with STM32CubeProgrammer application ? – Guillaume Petitjean Aug 17 '20 at 07:30
  • I don't fully understand your question. I am using the STM32CubeIDE for my application development and to flash the application onto the MCU, if that answers your question. I do have to use the standalone ST-Link utility to clear the RDP bytes once set though. The IDE (using gdb) cannot read or write to the flash after my application enables RDP. – Joshua DeWeese Aug 17 '20 at 19:02
  • STM32CubeProgrammer is not an IDE it is a tool to connect to the STM32 and read / write its memory. Just to check if it is a tool issue or not – Guillaume Petitjean Aug 18 '20 at 08:00
  • Ah ok, I downloaded and tried it out. It does fail, but gives a little more insight in its embedded console window. It's interesting that it looks like it tries twice. The first time, it looks like there is some bytes exchanged between the programmer and bootloader and then some failure. The second time the failures are timeouts. I am guessing that is after the chip has rest and is out of the bootloader at the point of the second try. I'll take a look at the bootloader protocol docs and see if the bytes that do get exchanged shed some light on what is going on. Thanks! – Joshua DeWeese Aug 18 '20 at 14:42
  • It turns out the two bytes (0x43 and 0x6F) that STMCubeProgrammer is reporting to receive back are 'C' and 'o' which are the first two chars of the string "Configuration loaded" coming from my application. So it would appear that the bootloader is making the jump to the application or resting the MCU as soon as it receives the first byte (0x7F) that it would normally calculate buadrate from. I.e it probably never even gets as far as configuring the UART in the MCU. – Joshua DeWeese Aug 18 '20 at 15:34

0 Answers0