Resetting an STM32H755 with secure area

[gpeh]

I am building a secure bootloader on the STM32H755, but I've bricked a couple of boards now trying to get the secure areas working.

I intended to use a "recovery" function on a button press to do a mass erase with protection removal. Then I can test enabling the secure areas via resetAndInitializeSecureAreas, and get back to square 1 nice and easy.

Except, it didn't work - I mass erased by device but the debugger doesn't work... So I assume the secure area is still present.

Before I brick yet another board, I'd like to check my assumptions.

If I follow the steps in "Flash mass erase with automatic protection-removal sequence", on the STM32H755, will that get me back to a "blank" device, with no secure regions?

Additionally, can I place the code that does that in RAM - IE in a non secure region? I ask because it feels wrong to erase flash while running from flash.

[Jocelyn RICARD]

Hello @gpeh ,

yes this would also be my approach.

I'm too busy right now to dig into this but this is in my toto list ! If you can wait until next week I can check on my side.

Best regards

Jocelyn

[gpeh]

@Jocelyn RICARD 

It works! The mass erase sequence I described previously does remove the secure areas correctly, and I can now recover a secured device. I must have previously interrupted it with a reset.

My issue now is that `exitSecureArea` does not jump to my application code, instead I get a hardfault. But it does reopen the JTAG, so that's nice at least. One more thing to work out I suppose!

---

For anyone arriving at this post in future, here is the process I followed to get here:

- Write the mass erase code

- Verify that it can recover a PCROP area

- Set your mass erase code to write a recognisable number to the secure area bounds

- Verify that your mass erase *does* write those numbers, and sets the DMES bit

- If that's all true, you should be able to clear a secure area and you can go ahead and hope you don't brick.

[gpeh]

@Jocelyn RICARDI now only have one remaining problem, which is that `exitSecureArea` cannot jump to my application correctly.

I can jump to an application also located in bank 1, but if I try to jump to an application in bank 2 it fails.

This is in contrast to the "manual jump", which works just fine.

__NO_RETURN static void jump_to_address(void* addr) {
    if (secure_mode_is_enabled()) {
        RSS->exitSecureArea((uint32_t)addr, REOPEN_JTAG);
    }

    BootloaderVectorTable_t const* const vectors = (BootloaderVectorTable_t*)addr;

    __set_MSP(vectors->sp);
    SCB->VTOR = (uint32_t)addr;
    __ISB();
    vectors->rst();
    hcf();
}

Is there a restriction that `exitSecureArea` can only jump to applications located in the same bank?

[gpeh]

I also notice that if you `exitSecureArea` and reopen the jtag, then you can read out all the secure area flash which I find very surprising - and in contradiction to the reference manual:

---

Only the Arm ® Cortex ®
-M7 core executing ST secure library or user secure application
can access it (Master ID filtering). In all other cases, accessing the secure-only area is
illegal (see below)

---

Is this correct or have I done something wrong? If I am correct I assume I will need to also use RDP level 1 to protect readout of the secure area via debugger...

[Jocelyn RICARD]

Hello @gpeh ,

About jump in second bank I will need to double check on my side.

About your second point, did you configure the secure area or just used the exitSecureArea function ? If secure area is setup, it should be closed.

Best regards

Jocelyn

[gpeh]

I configured the secure area using `resetAndInitializeSecureAreas`.

SECURITY bit is 1, secure bounds are valid:

But as you can see I can happily read out the memory region

[Jocelyn RICARD]

Hi @gpeh ,

I made a quick test:

• I can confirm that exitSecureArea supports second parameter to control jtag reopening. After launching following code, the JTAG is open

RSS_API->exitSecureArea(userAppAddress, RSS_ENABLE_JTAG_AT_EXIT);​

• If the user application is in second bank the call is also working fine. 

• When I set first sector of bank1 as secure memory, then launch user application on second bank, and then connect in hotplug mode with programmer, I see zeros displayed when I read first sector of first bank. All remaining flash is visible. This is expected behaviour of secure memory.

All this keeping RDP level to 0

For testing, I'm using a Nucleo-H755ZI-Q  NUH55AIQ$AT3 with revision V.

Best regards

Jocelyn

Best regards

Jocelyn

[Pavel A.]

@Jocelyn RICARD Excuse me for jumping in. What exactly means RSS_ENABLE_JTAG_AT_EXIT: ability to connect debugger in hotplug mode or also ability to read the secure memory from debugger interface?

[Jocelyn RICARD]

Hi @Pavel A. 

this additional parameter to the call of RSS function exitSecureArea will only make JTAG available for hotplug connection.

The secure memory is locked when cpu executes code in user flash: no way to access it from code neither debugger.

Best regards 

Jocelyn

[gpeh]

@Jocelyn RICARD 

Running again, I now see the memory zeroed out - I don't know why that was acting weird before, perhaps just something in CubeProgrammer.

And my bank1/bank2 issue was because `exitSecureArea` does not set the vector table location. My image in bank 1 set its own VTOR at startup - my image in bank 2 did not. So jumping to the bank 2 image failed.

Thank you for all your help Jocelyn, it's been a real slog until you got involved. Beste!