Summary
In a secure application, it is common that one would need to take simultaneous advantage of both flash memory read protections (RDP) and the TrustZone® controller. In this configuration however, there is a possibility of putting the device into a semilocked state in which the debugger does not connect. Depending on the option bytes at the time of the locked state, you could possibly be permanently locked from connecting the debugger to the device. This article describes the nature of when the lock state occurs and how to best avoid and alleviate the situation.
1. Inducing the Locked State
The locked state occurs any instance that the device is configured to such that
- RDP is level 1.
- TrustZone® is enabled and the MCU is running code only from a secure region.
This is why if you attempt to write RDP to level 1 in STM32CubeProgrammer while the TrustZone® is activated, you get a warning:
2. Why does the lock state occur?
STM32CubeProgrammer gives us a brief warning, but we need to look deeper to understand why the locked state could occur. AN5347 section 7.1 has a description of how the device behaves when RDP level 1 is enabled with TrustZone®, both when executing secure and nonsecure code.
As can be seen above, there are a couple of situations that can occur with RDP level 1 and TrustZone®:
- Executing nonsecure code: In this state, the debugger is connectable.
- Executing secure code: The debugger won't be connectable. To connect again, you must disable RDP. The only way to disable RDP since the debugger cannot be connected when executing secure code is to boot from RSS, that is, the system memory bootloader.
When executing secure code in the lock state, the only way to make the device connectable is to enter the system memory bootloader.
In this situation, avoiding a permanent lockout of the device depends on our ability to enter the system memory bootloader.
3. Recovering the device
At this point, whether or not you are able to recover the device depends on the configuration of the nSWBOOT0.
If nSWBOOT0 = 0 prior to entering the locked state, you are permanently locked out of connecting to the debugger on this device.
nSWBOOT0 determines whether or not the entry of the system memory bootloader/RSS is determined by the physical BOOT0 pin, or the nBOOT0 option bit. If nSWBOOT0 = 0, the boot location is determined by the nBOOT0 option bit. Since you cannot connect to the debugger, you are never able to connect to the device to toggle the nBOOT0 bit. This means that your device will be permanently locked out of debugging since there are no options to revert RDP to level 0 at this point.
If nSWBOOT0 = 1 prior to entering the locked state, you can use the BOOT0 pin to enter the RSS/system memory bootloader and revert RDP to level 0.
If you are using custom hardware in which you cannot access the BOOT0 pin, you will once again be out of options to recover the device. However, if you can access the BOOT0, you can recover the device by connecting BOOT0 pin to VDD voltage, then power cycling the device. Upon boot, the device should be executing code in the system memory, and therefore the debugger should connect. Once connected, revert RDP to level 0 in the option bytes. Remove VDD from BOOT0 and power cycle again. The U5 should be executing code from user flash again, except the debugger can be connected as usual.
4. Conclusion
Although the potential to permanently lock out the debugger exists on the U5, awareness of the issue allows for options to avoid this locked state. In summary, here are a few suggestions to help avoid and mitigate being locked out of your device:
- When developing an application with TrustZone® enabled, always develop your application in a way where secure code call nonsecure code. For instance, the default state of the application should be a loop in nonsecure code, and the application should only temporarily run code from secure regions in response to external conditions. In this way, you ensure that the firmware will inevitably reach a point where it executing nonsecure code so that you can connect a debugger.
- As a second safeguard, set nSWBOOT0 = 1, allowing you to use the system memory bootloader as a way to revert RDP to level 0. If you are developing on custom hardware, it is usually a good idea to give yourself access to the BOOT0 pin in general, but especially in this case.
