Issue with STM32H735 Bootloader in RDP Level 1 (0xBB) Mode

[SHm]

Hello,

I’m working with the STM32H735, and I need to enter bootloader mode to program the microcontroller. I modify the SYSCFG->UR2 register to set the address to 0x1FF00000, then perform a software reset. I use this method because I have no control over the BOOT0 pin (it's directly connected to GND) and the reset pin. After the reset, I use STM32_Programmer_CLI.exe to program the microcontroller with the following python script:

import subprocess

# Define the path to STM32_Programmer_CLI.exe
stm32_cli_path = "STM32_Programmer_CLI.exe"

# Define the commands to be executed
command1 = [stm32_cli_path, "-c", "port=COM7", "br=115200", "-rdu"]
command2 = [stm32_cli_path, "-c", "port=COM7", "br=115200", "-e", "all", "-w", "Test.hex", "-v", "-ob", "rdp=0xBB"]

try:
    # Execute the first command
    result1 = subprocess.run(command1, capture_output=True, text=True, check=True)
    print("Command 1 Output:")
    print(result1.stdout)
    
    # Execute the second command
    result2 = subprocess.run(command2, capture_output=True, text=True, check=True)
    print("Command 2 Output:")
    print(result2.stdout)

except subprocess.CalledProcessError as e:
    print(f"An error occurred while executing the command: {e}")
    print(f"Error Output: {e.stderr}")

This works fine when the microcontroller is in unprotected mode (RDP=0xAA). However, when RDP is set to 0xBB, after the software reset, the bootloader does not program the microcontroller (I get a timeout error). I see that the Flash memory is empty after this process, so it seems the protection is disabled temporarily, but the programming of the .hex file does not proceed.

Has anyone encountered a similar issue or have any suggestions on how to resolve this?

best Regards,

[SHm]

the STM32H735 I’m using has a single flash bank, so I can’t load firmware to a separate bank

[AScha.3]

ok,

so : how big is program max. ?  

[SHm · Accepted solution]

Hello,

I found a solution to modify the RDP level from a function that runs directly from SRAM. This approach is necessary because I do not have control over the BOOT0 and NRST pins (BOOT0 is tied to 0V, and NRST is connected to 3.3V), which means I cannot manually trigger the bootloader through hardware. Here are the steps:

1. Disable IRQs: The first step is to disable all interrupts to ensure there are no disruptions during the critical operations.

2. Adjust FLASH Wait States: Set the FLASH wait states to FLASH_LATENCY_7 to ensure stable operation while working with the memory.

3. Change BOOT0 Address via Option Bytes: Modify the BOOT0 address through the Option Bytes to point to the bootloader. This involves changing the Option Bytes configuration to set the boot address accordingly.

4. Change the RDP Level to Level 0: Adjust the RDP (Read Protection) level back to Level 0 through the Option Bytes. This change will initiate a mass erase of the FLASH memory.

5. Wait for the Mass Erase to Complete: Monitor the status of the FLASH controller to ensure the mass erase is completed before proceeding.

6. Perform a Software Reset: Once the mass erase is done, perform a software reset to apply the changes and restart the microcontroller.

7. Bootloader Launch and Flashing: Use the STM32 Programmer CLI to flash the firmware, specifying the BOOT0_CM7_ADDR0 option to set the appropriate boot address. This ensures that after the reset, the microcontroller will boot from the correct memory region.

Best Regards,