2024-11-06 12:35 AM - edited 2024-11-06 03:43 AM
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,
2024-11-06 02:10 AM
Hi. See RM0468 Reference manual. With RDP Level 2 boot from RAM and System Flash memory are disabled.
If you want to use RDP Level 2, you must write your own loader.
2024-11-06 02:32 AM - edited 2024-11-06 03:01 AM
Hello,
Another approach I’m considering is to disable the RDP level directly through code before attempting the bootloader entry. Here’s the outline of the process:
I would copy the code that changes the RDP level and initiates the software reset into RAM, then execute it from there.
This way, I would effectively downgrade the RDP level to allow bootloader access and proceed with programming.
Does this approach seem feasible, or are there any potential issues with executing the RDP downgrade and reset sequence from RAM?
2024-11-06 02:58 AM
>Has anyone encountered a similar issue or have any suggestions on how to resolve this?
1. There is no "issue" here with the chip. The "issue" is just stupidity and ignorance.
2. To resolve "this" :
A: rtfm. Before setting any RDP level !
B: Replace (now useless chip) and try again.
C: And trust the rm, if read rm :
2024-11-06 03:11 AM - edited 2024-11-06 03:47 AM
Apologies for the confusion. I made a mistake in the title. It should have read "Issue with STM32H735 Bootloader in RDP Level 1 (0xBB) Mode" instead of "Issue with STM32H735 Bootloader in RDP Level 2 (0xBB) Mode."
2024-11-06 03:44 AM
I corrected the title, I'm talking about Level 1