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

[MCost.4]

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:

[MCost.4]

Hello @Jocelyn RICARD 

No, I'm not able to connect to the bootloader with UART or USB. I looked at AN2606 - STM32 microcontroller system memory boot mode to check if additional configurations were required (Table 2 - Pattern 12) but I'm unable to access and change (i) TZEN, (ii) nSWBoot0 and (iii) NSBOOTADD1.

[Jocelyn RICARD]

Hello @MCost.4 ,

well I'm afraid there is no solution to recover the board.

I will try to find time to have a look to this setup and understand what could have happen.

I would suggest next time to start your test by disabling the security protections activation in the secure boot to check everything is working fine. This will avoid the risk to brick your board.

Best regards

Jocelyn 

[Jeff Tenney]

@Jocelyn RICARD I can start a new thread if needed, but I just bricked a U585 IOT kit.  The last thing I remember doing is attempting a TZEN regression in CubeProgrammer. The ST-LINK can't connect over SWD anymore (various errors exactly like @MCost.4). So I figured I could use the BSL (or the secure BSL) so I set BOOT0 high (SW1) and reset. CubeProgrammer can't connect over UART and the U585 USB port doesn't enumerate -- no DFW devices.  It's as if the BSL isn't even running.  What could have happened?

I had been experimenting with TZEN, RDP Level 1, Mass Erase, SECWMx_PSTRT and SECWMx_PEND.  Is there any combination of those settings in any order that might have bricked the U585?  If so I may have done something in the wrong order, as I am experimenting.  I did successfully regress TZEN before, so I'm not sure how it could have gone wrong this time.

I am using the latest STLink fw V3J15M6 and also tried the STLink fw delivered with CubeProgrammer (V3J13M4) and have tried with and without disabling the STLink's MSC device.  Tried Hot Plug, Normal, Reset, etc. No luck.

Thank you.

[Jocelyn RICARD]

Hello @Jeff Tenney ,

What you need to understand is that one you have set RDP Level 1, you can only connect to the target with debugger if CPU runs in non secure state. And connection can only be in HOTPLUG mode.

As the Cortex-M33 boots in secure, you should have a secure code that could jump to non secure area.

In user flash it is easy to make a mistake and not being able to connect.

In this case, only way is to set BOOT0 to VDD to enable embedded system bootloader. In this case, Cortex-M33 boots in a system secure code that jumps to non secure bootloader.

If you cannot connect to system bootloader this could be related to option bytes settings:

The most likely is that nSWBoot0 is set to 0 meaning you don't use BOOT0 pin to decide to jump to bootloader but use nBoot0 option byte value. This nBoot0 should also be set to 0.

Another reason why you would not jump to system bootloader is the BOOT_LOCK option byte set.

One good practice when enabling with RDP Level 1 with TrustZone enabled is to check before:

1) That your firmware is running well and stays in non secure (A non secure firmware that constantly calls secure services can be difficult to connect)

2) Alternatively, that nSWBoot0 is set to 1. Even check before switching to RDP Leve l1 that you can enable bootloader by setting BOOT0 to VDD.

Best regards

Jocelyn

[Jeff Tenney]

@Jocelyn RICARD Thank you Jocelyn for those tips.

I can't connect to the system bootloader even after verifying that BOOT0 is set to VDD.  I have tried true power reset (pull JP3, wait, replace JP3) and also the reset pin (black button).  The system bootloader doesn't seem to be running.  That puts the blame squarely on option bytes, but I never changed nSWBoot0 nor BOOT_LOCK.  I was experimenting only with TZEN, RDP Level 1, SECWMx_PSTRT, and SECWMx_PEND, and I was using CubeProgrmmer to do it.  I think maybe this time I had tried setting RDP to level 1 first and then setting TZEN (not sure).  I believe the last thing I did was to use CubeProgrammer to revert TZEN and RDP together.  CubeProgrammer seemed to encounter some kind of error but I don't remember any specifics -- I got errors from CubeProgrammer regularly.

The application code I was experimenting with just before bricking the unit was a secure-only application.  It uses STOP modes heavily.  I wonder if the use of STOP modes cause connection issues with the STLink, and if CubeProgrammer misprogrammed the option bytes or left them in an inconsistent state as a result.

I would normally attempt to reproduce the error with a new IOT kit, but in this case the consequences are too permanent to support meaningful experimentation.

Jeff

[MCost.4]

Hi @Jocelyn RICARD 

In my case, I never flashed my custom application to the board as the STM32Cube Programmer returns the error I mentioned only by executing the regression script from TF-M (the one I posted above). My custom application would only be flashed after the regression. That said, I never flashed anything to the user flash (the board was brand new). As long as I understand, the regression script from TF-M only configures to the Option-Bytes. As the regression script seems to be fine, my guess is that the version of STM32Cube Programmer I used has some flaw or bug. Unfortunately, I have to wait for a new MCU so I can test with older versions of the Programmer. 

@Jeff Tenney which version of STM32Cube Programmer are you using?

[Jeff Tenney]

@MCost.4 I'm using v2.16.  I am also a little suspicious of CubeProgrammer here, but I don't have much evidence -- again because the consequences are so permanent.

[Jocelyn RICARD]

Hello @MCost.4 and @Jeff Tenney ,

I tried to reproduce your issue and couldn't brick my L5 Nucleo board.

What I can tell is that this --hardRst option must be removed from the script (line 24).

The consequence of this option is that at least 2nd and 3rd programmer commands will not work properly. 

I'm still not sure how it is possible to end-up in such situation. Normally RDP in all TFM configurations is not activated in development mode which is the default configuration. And as long as RDP is not enabled you should have issue (at least for the L5 case)

For STM32U5 case, if RDP is set the regression script will not do anything because it tries to connect under reset which is not possible once RDP is enabled. And other commands in hotplug mode have no impact when RDP Level 1 is set.

So I have no clue how you could end up in such situation

Best regards

Jocelyn

[Jeff Tenney]

Thank you @Jocelyn RICARD for the perspective.  It helps.

I will get another U585 IOT kit and carefully track each step I take.  If I brick it, then I'll have a record of the steps that cause it.

Jeff

[Jeff Tenney]

Hi @Jocelyn RICARD and @MCost.4 

I received another U585 IOT kit and did some experimenting.  It appears my specific issue is that CubeProgrammer does not handle low-power modes correctly.  Here's what it looks like after a hot-plug SWD connect to a target using low-power sleep:

There are no error messages and no indication anything has gone wrong.  But the option bytes shown are not correct.  And the application on the U585 continues to run -- which is odd considering CubeProgrammer indicates it is "connected" to the U585.  I suspect in my experimenting a few weeks ago I didn't notice the problem and clicked "Apply" after making some minor change.  In fact I think I remember wanting to experiment with enabling TZ *after* setting RDP to level 1.  So I may have click the TZ check box and clicked "Apply".  Option bytes set this way would explain my having a bricked U585.

I would rather not try it again on my new kit 😉, but I think this explanation is plausible.