Failing to provision Secure Manager

[amolina-nxt]

We're trying to provision Secure Manager on our H573ZI-based engineering prototype boards.
We've only successfully provision only one out of three and the successful one took several tries.
We're using the same provision.bat/provision_auto.bat (from SMAK) that works on the H573II DK board almost all the time.

In the failed cases we get

Warning: Option Byte: SECBOOT_LOCK, value: 0xC3, was not modified.
Warning: Option Bytes are unchanged, Data won't be downloaded
Time elapsed during option Bytes configuration: 00:00:00.003
Warning: Option Byte: SECBOOTADD, value: 0xC0000, was not modified.
Warning: Option Byte: SECWM1_END, value: 0x7F, was not modified.
Warning: Option Byte: SECWM1_STRT, value: 0x0, was not modified.
Warning: Option Byte: SECWM2_END, value: 0x7F, was not modified.
Warning: Option Byte: SECWM2_STRT, value: 0x0, was not modified.
Warning: Option Byte: SRAM1_3_RST, value: 0x1, was not modified.
Warning: Option Byte: SRAM2_ECC, value: 0x0, was not modified.
Warning: Option Byte: SRAM2_RST, value: 0x0, was not modified.
Warning: Option Bytes are unchanged, Data won't be downloaded

Then further into the script

Get RSSe status...
Error: Execution of RSS CMD failed, returned value = 0xF5F5F5F5 
Error: Failed to get RSSe Status!
Error: Cannot launch RSSe..

Note: BOOT0 pin is tied to GND.

Any suggestions to what we should check to make Secure Manager provisioning more reliable?

[Frantz LEFRERE]

Hello @amolina-nxt 

FYI : A new version of CubeProgrammer is available.

"We're using the same provision.bat/provision_auto.bat (from SMAK) that works on the H573II DK board almost all the time."

I've never faced issue with DK board. Could you describe how it fails with DK board  in your case ? And how I can reproduce this issue ?

On your board, could you please do a full regression with script and dump the option byte ?

[amolina-nxt]

I forgot to mention that our engineering prototypes transitioned to PROVISIONING product state (0x17) and we able to use regression.bat to transition back to OPEN product state.

We don't seem to have an issue with the H573-DK boards.
The provision fails were early on when we were first playing with the SMAK application.
We're using STM32CubeIDE 1.14.0 (which seems to have it's own copy of STM32_Programmer_CLI.exe ver 2.15.0)

We had standalone STM32CubeProgrammer is v2.14.0, but switched to STM32CubeProgrammer v2.15.0.
However, still the same issue

Attached is dump of FLASH and SBS registers by STM32CubeProgrammer v2.15.0 connected to H573ZI-based engineering prototype board after failed Secure Manager provision (product state still 0x17)

[Frantz LEFRERE]

Could you describe your SWD/NRST connection ? 

You may try to decrease the SWD frequency to check if this improve the behavior.

[amolina-nxt]

We think it's pretty much our H573ZI-based boards.
SM/provisioning_auto.bat works on the H573II-DK with no issues.
We assume there is no differences in behavior between H573II and H573ZI for provisioning SM.

I've been trying to blame some transient on BOOT0 pin, but so far looks to be logic "0", though I noted that the STM32H573ZI datasheet BOOT0 has  different high/low voltage levels from the other GPIOs.

It's been noted there is some noise heard (from some relays) when attempting to use provisioning_auto.bat and regression.bat.
This is currently being investigated.

During SM provisioning, are only the BOOT0 and SWD pins that are in use and no other pins are accessed?

[amolina-nxt]

So, far still have not been able to provision Secure Manager on 3 out of 4 boards.

I've taken the original provisioning.bat, copied to another script file install_sm.bat that just does downloading of the already built files (by provisioning_auto.bat), but with verbose output (vb=3, echo on) turned on.
attached here under the name install_sm_bat.txt, since the "drag & drop here" doesn't allow *.bat files.

I captured the script output provisioning SM into a  STM32H573I-DK board successfully (DK_SM_Install_20240113-001736.log)
I captured the script output of provisioning SM into a failed attempt on one of engineering boards (SPC3_SM_Install_2024113-001313.log)

I see some differences on the commands that are sent to the DK vs. our board.
Is there some programmatic differences between the STM32H573II on the DK board vs. our STM32H573ZIT6 engineering boards?
Any significant operating differences between the DK's on-board ST-Link (ST-Link FW V3J13M4) vs. external STLINK-V3Set (FW V3J13M4B5S1)?

[Frantz LEFRERE]

hello @amolina-nxt ,

I did a quick test and connect a external STLINK-V3Set (FW V3J13M4B5S1) to the STM32H573II DK board and used your script. No issue for the secure manager provisioning. 

I will rise an internal case to double check with tools team.
Is the schematic of your board has been reviewed by any ST people ? If not, could you provide it ? If you don't want to disclose it on the forum, I can send you a private request just let me know.

Best regards,

Frantz 

[amolina-nxt]

I think there has been sporadic attempts to get more direct ST FAE support, but due to holidays, PTO, and just recent availability of boards with correct STM32H573ZI on them, the interactions on both sides has been somewhat spotty.

BTW, does the RSS and/or SM depend on USART1 being a serial console?
Currently, USART1 is allocated to a different external device.
That's one difference between the DK and our engineering boards.

[amolina-nxt]

So, I have a Nucleo-H563ZI development board, could we simply swap out the STM32H563ZI and put a STM32H573ZI and then try provisioning SM on to it?
Or, would other changes need to be done to the Nucleo board to use a H573ZI or not even viable?

I know the Nucleo-H563ZI has USART3 routed to the ST-Link VCP for the serial console, while the H573II-DK uses USART1.

[amolina-nxt · Accepted solution]

We removed some resistor and another component connected to the NRST and Secure Manager provisioning is now working without errors---10 cycles of provisioning and regression executed successfully.

I think this issue is resolved, though we need to investigate why those connected components were impacting provisioning.