Removing ReadOut Protection with UART port 3 on system bootloader

[JGagnon]

Hello,

I am trying to figure out the ReadOut protection configuration from the CLI tool (STM32_Programmer_CLI) and I am encountering an issue.

Setup :
OS : Linux Mint
MCU : STM32F439
Board : Custom
STM32_Programmer_CLI version : 2.19.0

We have this custom board and use the system bootloader to flash a firmware when needed. Once the firmware is flashed, the RDP is enabled.

When we want to flash the board again, we disable the RDP, flash the board, and reflash the board again.

This works well with a debugger , using this command :

STM32_Programmer_CLI -c port=SWD -ob RDP=170

we can disable the RDP.

However, we want to do the same thing from the UART3 in system bootloader and it doesn't work.

When I try to disable the RDP with the UART3 port with the following command :

STM32_Programmer_CLI -c port=/dev/ttyUSB1 -ob RDP=170

 i get the following error :

-------------------------------------------------------------------
                        STM32CubeProgrammer v2.19.0                  
      -------------------------------------------------------------------

Serial Port /dev/ttyUSB1 is successfully opened.
Port configuration: parity = even, baudrate = 115200, data-bit = 8,
                     stop-bit = 1.0, flow-control = off
Activating device: OK
Board       : --
Chip ID: 0x419 
BootLoader protocol version: 3.1
Warning: Device is under Read Out Protection
Error: a read Operation failed, please check if any memory protection mechanism is active.

The readout protection documentation is scarce and I haven't any indication anywhere that the UART3 is not a valid port while in system bootloader, to disable the RDP and go through the same process as the ST-Link debugger.

Is there any other commands I need to do to be able to disable the RDP with the UART3?

Thank you.

[Amine_Jridi]

Hello @JGagnon,

The device is under Read Out Protection, if you want to disable the RDP using UART you can enable the 'Read Unprotected' by using the '-rdu' command: 

STM32_Programmer_CLI -c port=/dev/ttyUSB1 -rdu

[JGagnon]

Hello Amine,

thanks for the help.

When running the command above, I get the following errors :

      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.19.0                  
      -------------------------------------------------------------------

Serial Port /dev/ttyUSB1 is successfully opened.
Port configuration: parity = even, baudrate = 115200, data-bit = 8,
                     stop-bit = 1.0, flow-control = off
Activating device: OK
Board       : --
Chip ID: 0x419 
BootLoader protocol version: 3.1
Warning: Device is under Read Out Protection
Disabling memory read protection...

Timeout error occured while waiting for acknowledgement.

Timeout error occured while waiting for acknowledgement.

Timeout error occured while waiting for acknowledgement.

Timeout error occured while waiting for acknowledgement.

Timeout error occured while waiting for acknowledgement.

Timeout error occured while waiting for acknowledgement.
Error: Unable to disable memory read protection

Timeout error occured while waiting for acknowledgement.
Error: GETID command not acknowledged!

Reemission of GetID command

Timeout error occured while waiting for acknowledgement.
Error: GETID command not acknowledged!

Reemission of GetID command

Timeout error occured while waiting for acknowledgement.
Error: GETID command not acknowledged!

Disabling memory Read Protection...

Timeout error occured while waiting for acknowledgement.

Timeout error occured while waiting for acknowledgement.

Error: Disabling memory Read Protection failed

 When looking at the memory after the error, I can see that the RDP was removed. However, my issue is that I can't chain commands, and this is an issue since there is no more firmware on the chip, I can no longer put the mcu into system bootloader through code.

With the debugger, I can do something like :

STM_Programmer_CLI -c port=SWD -rdu -w <firmware.bin> 0x0800000

 and the system will stay in system bootloader, remove the RDP and then flash the firmware.

output :

      -------------------------------------------------------------------
                        STM32CubeProgrammer v2.19.0                  
      -------------------------------------------------------------------

ST-LINK SN  : 066BFF555071494867184947
ST-LINK FW  : V2J46M31
Board       : NUCLEO-G071RB
Voltage     : 0.02V
SWD freq    : 4000 KHz
Connect mode: Normal
Reset mode  : Software reset
Device ID   : 0x419
Revision ID : Rev 5/B
Device name : STM32F42xxx/F43xxx
Flash size  : 2 MBytes (default)
Device type : MCU
Device CPU  : Cortex-M4
BL Version  : 0x0


Disabling memory Read Protection...
Time elapsed during option Bytes configuration: 00:00:17.902

Memory Read Protection disabled successfully
Opening and parsing file: firmware.bin


Memory Programming ...
  File          : firmware.bin
  Size          : 161.11 KB 
  Address       : 0x00080000 



Erasing memory corresponding to sector 0:
Download in Progress:
[==================================================] 100% 

File download complete
Time elapsed during download operation: 00:00:01.135

The error above makes this impossible. Is there anythine else I can try?

Thanks,
Jean-Francois

[Amine_Jridi]

Hello @JGagnon,

It seems the issue might be related to the configuration of UART3, specifically the pull-up mode on the RX and TX pins. I recommend verifying the pull-up settings on PC10/PC11 (AN2606). Or trying UART1 to see if it resolves the problem since it works fine on my end.

Thanks,

Amine.

[JGagnon]

Hello Amine,

my understanding from AN2606 is that when in system bootloader, PC10 and PC11 are set as input with pull-up according to table 64. This is why we went with USART3 on PC10/PC11. Is my understanding wrong?

When giving control to the system bootloader, we do not have control over how the pins are configured right? So the moment that the connection is made, the pins should be configured correctly.

There is a RS-485 receiver, so I will have to check if there is any impact on the line coming from the chip, but since the issue is happening after the connection, I feel like my understanding of the pin configuration isn't good.

What is your setup for testing?

Thanks,
Jean-Francois