Trusted Firmware-M v2.1.0 - Bricked Nucleo-L552ZE-Q

MCost.4 · ‎2024-05-20

Hello,

I followed this tutorial to add an example secure partition in TF-M ( https://tf-m-user-guide.trustedfirmware.org/integration_guide/services/tfm_secure_partition_addition.html ) and then followed these instructions to flash the application to my Nucleo-L552ZE-Q board ( https://tf-m-user-guide.trustedfirmware.org/platform/stm/common/stm32l5xx/readme.html ). However, the script regression.sh returned the error:

Error: Cannot connect to access port 0!
If you are trying to connect to a device with TrustZone enabled please try to connect with HotPlug mode.
If you are trying to connect to a device which supports Debug Authentication with certificate or password, please open your device using it.

After this, I am unable to connect my board STM32Cube Programmer or to flash any application using Keil MDK ARM, CubeIDE, etc. The same error is returned every time. Before I runned the regression.sh script, the board was working as expected and I was able to flash simple applications (non using TF-M) to the board. Does someone know how can I fix this problem?

Here is the configuration I have in STM32Cube Programmer:

Jocelyn RICARD · ‎2024-06-18

Hello @Jeff Tenney ,

I'm not sure what you wanted to achieve by enabling TZ after setting RDP Level 1. The usual sequence is to set TZEN, flash secure and non secure applications and then set RDP. You could flash secure and non secure and then set TZEN but RDP is always the last thing to change.

Now, the issue you see seems related to the connection setting in hotplug mode. I guess that with normal or under reset you get correct values of option bytes. So, to reproduce you have a software that switches to sleep mode without TZ enabled and you connect in hotplug. Right ?

Best regards

Jocelyn

Jeff Tenney · ‎2024-06-18

I'm not sure what you wanted to achieve by enabling TZ after setting RDP Level 1.

In a word, nothing. I'm not even on the product lifecycle yet. I'm just curious about how TZEN works and was experimenting. But I can think we can safely ignore that part of the story as I am not very confident about precisely what I was doing when I bricked the unit.

I guess that with normal or under reset you get correct values of option bytes. So, to reproduce you have a software that switches to sleep mode without TZ enabled and you connect in hotplug. Right ?

Yes, immediately after a "normal" connect or an "under reset" connect, the option bytes are correct. And yes, connecting in "hotplug" mode seems to be a primary culprit. As in this example:

Use CubeProgrammer to connect via SWD in "normal" mode.
Set TZEN. Click Send.
Load an application that is secure only and that uses sleep mode heavily.
Verify application runs (LED blinks).
Next steps are working toward setting RDP to level 1.
Use CubeProgrammer to connect via SWD in hotplug mode.
(Notice CubeProgrammer didn't read correct option bytes but acts like it did.)
Set RDP to level 1.
Click Send.

I get to step 8 but am afraid to do step 9 in case CubeProgrammer actually does it. Besides RDP, the option bytes are all zero, which (I think) would disable the TI BSL and brick the U585.

Here's a scenario without the use of hotplug:

Load an application that is essentially security agnostic and that uses sleep mode heavily. (This application runs with TZ disabled and it also runs secure only when TZ is enabled.)
Verify application runs (LED blinks).
Use CubeProgrammer to connect via SWD in "normal" mode.
Set TZEN. Click Send. See the following errors:
(Notice CubeProgrammer didn't read correct option bytes but remains connected and now shows all zeros for the option bytes.)
Set RDP to level 1.
Click Send.

Again I have not actually clicked send in this scenario in case CubeProgrammer actually does it.

Note that in all scenarios, the option to "debug in Low Power mode" is checked.

The primary issue seems to be this -- user applications that use low-power modes can really confuse CubeProgrammer. When CubeProgrammer must allow the target to run (eg, during hotplug connect or OBL launch), the target might use low power and quietly break access to the option bytes and maybe more. At this point I'm still only guessing that these issues allowed me to brick the 'U585.

@Jocelyn RICARD

Jocelyn RICARD · ‎2024-06-19

Hello @Jeff Tenney ,

I tried to reproduce this behaviour.

I used SLEEP example STM32Cube_FW_U5_V1.5.0\Projects\NUCLEO-U575ZI-Q\Examples\PWR\PWR_SLEEP\

It it blinking a LED for 5 seconds and then goes to SLEEP mode. You wake up with interrupt from user button of the Nucleo. LED blinks again 5 seconds and goes back to SLEEP.

Connecting to the target in Normal and Under reset, option bytes are visible. Connecting in HOTPLUG mode, option bytes are read to 0. This is not dependent on TZEN nor related to debug in low power mode as this only applies to STOP mode and probably STANDBY.

In hotplug the MCU is not stopped. So, to be able to read option bytes you need to go to CPU and press halt.

Reading again option bytes gives you right value.

In any case, for such scenario I would advise using connect under reset so that you make sure your device is not in SLEEP state when changing option bytes.

I tested TZEN transition which works fine.

Then set RDP Level 1. After a power-on reset the firmware runs as expected.

In this state, STM32CubeProgrammer cannot connect to the target because it stays in secure state.

To be able to regress the device you must ensure before setting RDP1 that when you connect BOOT0 to VDD, the MCU boots in the system bootloader. This can be checked using the CPU tab where PC should be at an address similar to 0xBF98462.

One you are sure you can switch to bootloader, you can enable RDP Level 1, using connect under reset !

If you want to disable TZ you need to do it at same time as RDP regression.

Best regards

Jocelyn

Jeff Tenney · ‎2024-06-19

Hello @Jocelyn RICARD and thanks for your reply.

Connecting in HOTPLUG mode, option bytes are read to 0. This is not dependent on TZEN nor related to debug in low power mode

Agree that TZEN and the debug setting are irrelevant. The real issue is that CubeProgrammer doesn't behave correctly when the target uses low-power sleep. The behavior is wrong even if you connect in "normal" or "under reset" mode, but the behavior is worse if you connect in "hotplug" mode.

If you want to try the 7-step scenario I shared above, which does not use hotplug mode, then please use the attached application firmware on a U585 IOT kit. You will see how easy it would be to accidentally trash the option bytes - which can easily brick the device. A user might simply "try again" to set TZEN after getting the error messages, and unwittingly send a bunch of zeros for the option bytes. (FYI, the attached application blinks the LED and sends UART output. It uses low-power sleep almost all the time, and it doesn't use stop/standby modes.)

In hotplug the MCU is not stopped. So, to be able to read option bytes you need to go to CPU and press halt.
Reading again option bytes gives you right value.

That is good info -- but in this case the Option Bytes UI won't show the Secure Area 1 and Secure Area 2, even if it finds TZEN set to 1. That isn't correct UI behavior.

In any case, I have a pretty good explanation for how I might have bricked my IOT kit. I think I used hotplug and didn't realize CubeProgrammer hadn't read the option bytes correctly. Then I changed one thing (probably RDP) and sent the (garbage) option bytes.

Thank you for your help!

Jocelyn RICARD · ‎2024-06-19

Hello @Jeff Tenney ,

OK I get your point. With your application, as you use SLEEP state immediately after startup, the STM32CubeProgrammer is not able to reconnect after setting option bytes, probably because this is not an initial connection. This results in an error and option bytes are set to 0.

I will raise the point internally.

"That is good info -- but in this case the Option Bytes UI won't show the Secure Area 1 and Secure Area 2, even if it finds TZEN set to 1. That isn't correct UI behavior."

When you are in RDP Level 1, you will never see secure related information. This is normal behavior.

This prevents from changing security related option bytes while being in RDP Level 1.

Best regards

Jocelyn

Jeff Tenney · ‎2024-06-19

When you are in RDP Level 1, you will never see secure related information. This is normal behavior.

I was on RDP Level 0. I couldn't see the security related options because CubeProgrammer read the option bytes incorrectly during hotplug connect. Halting the CPU and then getting a proper read of the option bytes does not make the security related option bytes appear, even though it probably should, because TZEN is 1.

Thanks again for all your help.