STM32_Programmer_CLI should handle more situations

[DavidEGrayson]

I'm using STM32_Programmer_CLI software v.2.20.0 to program an ST Nucleo board (NUCLEO-C071RB).

I wish the software were better at automatically handling situations that make it fail.

For example, this command does work normally for uploading firmware to the board:

STM32_Programmer_CLI --connect port=swd --download firmware.elf --start

However, if you have enabled read-out protection (RDP) by setting RDP=0 in the option bytes, then it fails with "Error: failed to erase memory"  (and for some reason, it prints that message twice).  If read-out protection truly does prevent you from erasing, the software should be smart enough to detect that RDP is on and then turn it off temporarily.  Instead, we have to manually ask the software to do that:

STM32_Programmer_CLI --connect port=swd -ob RDP=0xAA --download firmware.elf --start

Next, if you have enabled write protection for a relevant portion of flash, the software fails with the same "Error: failed to erase memory" error messages. It seems like it should be smart enough to temporarily disable write protection in order to make the download succeed. Instead, we have to manually ask the software to do that:

STM32_Programmer_CLI --connect port=swd -ob RDP=0xAA -ob WRP1A_STRT=0x3F -ob WRP1B_STRT=0x3F --download firmware.elf --start

Next, if your firmware disabled debugger access to the core by setting DBG_SWEN in FLASH->ACR, the software will fail with the error messages "Error: Unable to get core ID" and "Error: No STM32 target found! If your product embeds Debug Authentication, please perform a discovery using Debug Authentication". The software should just automatically use its connection to the target's RST pin to work around this, but it does not. I tried using "--hardRst" and/or "--rst" right after "port=swd", but it did not help. Instead, the workaround for this problem is that you must hold the Nucleo's RESET button down with your finger while starting the software, then release it after the software has started running and is waiting.

It kind of feels like the STM32_Programmer_CLI is a scripting language with some useful commands in them, but to achieve my end goals I need specialized knowledge of how STM32 chips are programmed, in order to figure out which commands to use and which order to put them in. I feel like the software would be more useful and enjoyable to use if it were a high-level program that allowed you to specify your goals in terms of the state of the microcontroller and its memory and then it takes care of all the details of making those goals happen, automatically handling situations that might interfere with that process.

I hope this post is useful to others working around these issues, and also that someone on the STM32CubeProgrammer team with decision-making authority sees it. Thanks!

[Kouthair · Accepted solution]

Hello David,

Thank you for your input.

From a device and security perspective:

Read and write protections are essential to safeguard user data and device integrity. The additional step is intentionally designed so that the user authorizes sensitive operations, such as lowering the RDP level and to not perform these actions automatically by default to prevent unwanted operations.

For example, allowing STM32CubeProgrammer to automatically change from RDP 1 to RDP 0 erases the flash memory, which can result in unintentional data loss.

Regarding the second point, it is expected behavior for STM32CubeProgrammer to not allow debugger read access if DBG_SWEN is set to 0.

Another thing is that STM32CubeProgrammer already operates at a relatively high level. You could simply connect to an MCU and program or erase the memory.

In summary, disabling these options automatically reduces user control over the device, removes a crucial protection layer and renders protections ineffective. It is necessary to take into consideration device security, protection of intellectual property, and prevention of unwanted interference.

I hope this has cleared any misconceptions, feel free to ask any question on our community.

Best regards,
Kouthair

[DavidEGrayson]

Google's AI helpfully told me to use mode=UR (which you can add after port=swd), and then the ST-Link will connect to STM32 while holding it under reset.  This means I can successfully program a chip where the firmware has cleared DBG_SWEN (or otherwise blocked access to the debug port) and I don't have to manually hold down the RESET button with my finger.  I'm not sure where I was supposed to go to learn about UR in ST's documentation, but hopefully this forum post will serve as a way to spread word about this useful feature.

I think I've finally arrived at a reliable programming command for the STM32C071RB:

STM32_Programmer_CLI --connect port=swd mode=UR -ob RDP=0xAA -ob WRP1A_STRT=0x3F -ob WRP1B_STRT=0x3F --download firmware.elf --start

---

When I'm flashing a microcontroller, I don't really care about its existing state, including the main flash, option bytes, RAM, and peripherals. The existing state was generated by scripts and code on my computer which are stored in version control, so that state can always be recreated. I just want to overwrite the microcontroller's state with a new state. Perhaps there could be a "--full-clear" option or something that gets the microcontroller to a fresh state so we can program it without any issues, and it would use all the tips I posted above.

I agree that read/write protections in the option bytes are important. Therefore you should never depend on your programming software to leave those bytes in a specific state. Your code should check the option bytes on startup and if they are wrong then either fix them using IAP or just refuse to run.

Now let's go through some of Kouthair's other points:

• "it is expected behavior for STM32CubeProgrammer to not allow debugger read access if DBG_SWEN is set to 0". This is technically true but we should spread the word about mode=UR, which typically sets DBG_SWEN to 1 (but not always, depending on the option bytes).
• "removes a crucial protection layer and renders protections ineffective": Definitely not. Just to be clear, I'm not talking about any change to the STM32 chips themselves. I'm only talking about making the programming tools smarter. If your security protections rely on the attacker not having good tools or not knowing how to use the tools, then it was already ineffective.