STM32H573VI: Bricked in "Provisioning" product-state while tring to applicate DA on device

[MattiaB]

Good morning everyone,
I need to apply the "Closed" product state to my device using the STM32H573VI.
I don't need TrustZone enabled and want to use a password for debug authentication.

I wanted to perform the operation via "code" using the HALs, but once I set the state to "Provisioning(0x17)" from "Open(0xED)," my firmware won't boot, and I can't even provision the *.obk file using the STM32CubeProgrammer.

bool ProductState::set(states newState)
{    
    FLASH_OBProgramInitTypeDef flashOptionBytes= {0};
    HAL_StatusTypeDef ret {HAL_ERROR};
    
    if(newState == states::Unknown) {
        Log::msg("Invalid product state\n");
        return false;
    }
    
    Log::msg("Setting product state to %s ...\n", toString(newState).c_str());

    HAL_FLASH_Unlock();
    HAL_FLASH_OB_Unlock();

    flashOptionBytes.OptionType = OPTIONBYTE_PROD_STATE;
    flashOptionBytes.ProductState = (static_cast<uint32_t>(newState) << FLASH_OPTSR_PRODUCT_STATE_Pos);

    Log::msg("Program state ...\n");
    ret = HAL_FLASHEx_OBProgram(&flashOptionBytes);
    if (ret == HAL_OK)
    {
        Log::msg("OB Launch ...\n");

        ret = HAL_FLASH_OB_Launch();
        if (ret != HAL_OK)
        {
          Log::msg("Error while execution OB_Launch : %d\n", ret);
        }
    }
    else {
        Log::msg("Error while setting OB Bank1 config state %s : %d\n", toString(newState).c_str(), ret);
    }
    
    HAL_FLASH_OB_Lock();
    HAL_FLASH_Lock();
    
    return (ret == HAL_OK) ? true : false; 
}

I then tried to do the entire process using the STM32CubeProgrammer on another board.
I'we followed the video: STM32H5:Product state 
- I flashed my application (a simple blinking LED) with IAR
- I changed the product state from "Open" to "Provisioning"

But no luck. Once the Provisioning state is set, I can't provide the *.obk file using the PROV dropdown.

Product state is 0x17 as correctly expected:

So both behaviours are equals using directly HALs drivers or STM32CubeProgrammer.
Can anyone please help me figure out what I'm doing wrong?
Thanks in advance for your help.

[Jocelyn RICARD]

Hello @MattiaB ,

please connect in hotplug mode. You will be able to provision the board.

Then please check you can do a regression in this state before going further.

This will validate that the DA obk you provided is correct.

By the way, I would recommend having a look to the wiki How-to to get started with a new feature

Best regards

Jocelyn

[MattiaB]

Hi @Jocelyn RICARD,

Also in hotplug mode I'm not able to provide the OBKey:

The STM32CubeProgrammer is the last downloadable:

[Jocelyn RICARD]

Hello @MattiaB,

please try using a STlink probe instead of J-Link probe.

It is possible the Segger does not properly support the provisioning through the programmer.

Other solution could be to use the PC Segger tools using up to date driver.

Best regards

Jocelyn

[MattiaB]

Good morning @Jocelyn RICARD,

Thank you — provisioning is now working.

I have two follow-up questions:

1. How can i test the regression in provisioning staate like you mentioned in the previous post?

2. From the FW application, is it possible to:

   • set the provisioning state without rebooting,
   • set the OBKey password
   • set the state to Closed
     

     This is necessary because, in production, we want the tool itself to apply the protection, rather than relying on an operator to activate it manually via the programmer.

     Thanks in advance, and please let me know if you need additional details.

[Jocelyn RICARD]

Hello @MattiaB ,

Now you are in provisioning state, just disconnect cube programmer and use DA tab.

You will be able to launch the discover.

Cryptosystems : STPassword

In the log you should get ST provisioning integrity status: 0xeaeaeaea.

Just select your password.bin file generated by TrustedPackageCreator and request FullRegression.

If it does not work, password provided is not the good one.

Regarding your second question, unfortunately you are in the specific case that will not work. The combination of TrustZone Disabled + Crypto part (STM32H573 here) does not support the provisioning from user firmware.

This should be fixed in a future chip release but I don't know when. This limitation is traced in the errata sheet (Chapter 2.2.35)

Best regards

Jocelyn

[MattiaB]

Thank you for the response @Jocelyn RICARD,

I powered the board, navigated to the "shield" icon, and pressed Discover.
Unfortunately, the discovery process failed.

When connecting to the target, I can see that it has clearly remained in the provisioning state.
I am not sure why the discovery fails. Do you have any idea what might be causing this?

Thank you again for your patience and the support you are providing. I look forward to your feedback.

[Jocelyn RICARD]

Hello @MattiaB ,

Can you check that you have connected the reset signal to the STLink Probe?

The Debug Authentication requires the control of this reset signal

Best regards

Jocelyn

[MattiaB]

Hi @Jocelyn RICARD,
if you mean the NJTRST it's connected to the STMLink probe as follows:

If you mean NRST, it is NOT connected to the STLink probe:

Let me know if it's correct.

[Jocelyn RICARD · Accepted solution]

Hello @MattiaB ,

I confirm that you need to control the NRST pin to make Debug Authentication work

Best regards

Jocelyn