H753 Target not found after security option byte

[Something0815]

Hey,

I tried to activate the HDP feature / secure software area on H753 following this documentation HDP secure area for STM32H7B3xx microcontrollers - Application note. I did only activate the security option byte not the secure software area itself. But I cannot connect via ST32 Cube Programmer anymore .- Error: No STM32 target found.

My procedure so far:
- Clear Flash

- Activate Security option byte to get access to the RSS code

- Implement jump in Bootloader via RSS_exitSecureArea - 0x1FF0 9514 (controller dependent)

- Flashed Bootloader and Application

- Cannot connect via Debugger Hot plug (and under reset as well)

- Did not activate secure software areas yet

 

Whats strange is, my display shows, that the application is started. Means, the jump via exitSecureArea does work. The application itself does as well works as expected.

 

My understanding of the security option is, that it 

- forces the boot through RSS (therefore the need to connect as hot plug)

- gives you access to RSS area (needed to call RSS_exitSecureArea() )

- does not have any further impact, as long no secure area is defined

 

I am pretty sure I did not set a secure software area. But even if I did so, would it explain the error message? I thought you can disable the secure software area via regression, which I would have done with the CubeProgrammer as well.

Does anyone has an idea how to restore the connection or more importantly what causes this issue? Can it be connected to the security bit at all?

[Jocelyn RICARD]

Hello @Something0815,

My understanding of the security option is, that it 

- forces the boot through RSS (therefore the need to connect as hot plug)

=> Yes

- gives you access to RSS area (needed to call RSS_exitSecureArea() )

=> Not necessarily. The usage of RSS_exitSecureArea should be used when you want to exit a secure area and at the same time, make this secure area no more visible from the user application. 

- does not have any further impact, as long no secure area is defined

=> I don't think so.

 

My procedure so far:
- Clear Flash

- Activate Security option byte to get access to the RSS code

=> Activation of security bit changes the boot from flash to boot from RSS. It does not give you access to RSS code. You can use the RSS_exitSecureArea() without enabling security bit. It will just go through, calling the address you provided.

- Implement jump in Bootloader via RSS_exitSecureArea - 0x1FF0 9514 (controller dependent)

=> This can be checked without setting security bit (as said above)

- Flashed Bootloader and Application

- Cannot connect via Debugger Hot plug (and under reset as well)

- Did not activate secure software areas yet

=> This is not normal. If you ONLY set the security bit, you can always connect in hotplug mode.

What could happen is that your bootloader reassigns the JTAG GPIOs for instance.

Also, if your bootloader is jumping rapidly to the application, the call to RSS_exitSecureArea disables automatically the JTAG.

If your bootloader is able to flash a new application, just set back JTAG or SWD GPIOs to their reset state in the application. You should be able to connect.

Best regards

Jocelyn

[Something0815]

Hello Jocelyn,

thanks for your input. I'm now quite cautios with this feature because of limited hardware.

As a result I want to test the jump without setting the security bit. 

 

1. I do not understand why the RSS code should be accesible at all

Reference Manual: "RSS software cannot be accessed (read, write, execute and debug) when the
STM32H750xB and STM32H753xI operate in Standard mode."

But I can read the memory address via debugger, so I expect it could be executeable as well.

 

2. Test the jump (security bit not set, secure software area also not set)

 

 

typedef struct
{
 void (*exitSecureArea)(uint32_t vectors);
} RSS_API_Table_t;

#define RSS_API ((RSS_API_Table_t *)0x1FF09514)

JumpFunction(){
[...]
//		void (*application_reset_handler)(void) __attribute__((noreturn)) = (void *)(*((volatile uint32_t *)(address + 4U))); 
//		application_reset_handler(); //0x08100004
	RSS_API->exitSecureArea(0x08100000);
}


----------------------------------------------------------
Applications linker script
/* Specify the memory areas */
MEMORY
{
 FLASH (rx) : ORIGIN = 0x08100000, LENGTH = 1024K-512
 [...]
}

 

The outcommented jump to the application works as expected. The exitSecureArea call not. 

Leads to debugger output: 

Error in executing 'cont' command ...

Target is not responding, retrying...

Target is not responding, retrying...

Target is not responding, retrying...

 

Debugger is stopped and application is not executed, which can be controlled via display.

 

Is it because of access permissions?
Is it a problem with the memory address? My old jump jumps directly to the reset handler, but in ST's example code exitSecureArea is always called with StartOfFlash I think.

 

3. Differences to H7B3

ST provides example code for the H7B3 controller (STM32CubeH7/Projects/STM32H7B3I-EVAL/Applications/HDP/HDP_Boot/Inc/RSS.h at master · STMicroelectronics/STM32CubeH7 · GitHub).

The function prototype of exitSecureArea() is slightly different. It has an addtional parameter if the debugger shall be activated afterwards. How does it behave on H753 - is it turned on per default?

 

Do you have any idea? (I did accept you last response as solution by accident and couldn't revert it.)

[Jocelyn RICARD]

Hello @Something0815 ,

"I'm now quite cautios with this feature because of limited hardware" : I don't catch what limitation you are talking about here. There are constraints to use the secure memory that a detailed in the reference manual, but limitations ?

1- The code that is executed after reset is protected and you cannot see it. The code that executes the jump is visible.

What is called RSS is usually the code that is protected, and RSSlib the code that can be called by user flash. But you shouldn't care about that.

2- Well, I don't know what happens. It should just work if address = 0x08100000 in your code. Also I don't catch your point about StartOfFlash. If you have a bootloader it is usually located at beginning of flash. The address of application is usually not at StartOfFlash.

3- Yes, as said in my previous post. Debugger is disabled by default on STM32H753. The application can enable it again by setting GPIO to their reset values.

No issue accepting the answer. By the way, did it help ?

Best regards

Jocelyn

 

 

 

 

[Something0815]

Hello Jocelyn,

thanks for the response. I've found the error which, I guess, explains the behavior. 

The application did not set the debug pins explicitly. It has relied on the reset behavior.

 

Reference manual:

The debug pins are in AF pull-up/pull-down after reset:
• PA15: JTDI in pull-up
• PA14: JTCK/SWCLK in pull-down    <- SWD init
• PA13: JTMS/SWDAT in pull-up      <- SWD init
• PB4: NJTRST in pull-up
• PB3: JTDO in floating state

As a result, the debugger is enabled after reset. But exitSecureArea() does disable the debug interface on STM32H753 per default as you said. And exitSecureArea() does not trigger any system reset. Therefore the debug pins (in my case SWD), must be set explicitly to enable the debug interface.

 

I guess that would explain it as well why I bricked my first hardware. As I said, I did only activate the SECURITY option bit. As a result the boot changes from flash to RSS.

- According to the reference manual we cannot debug while in RSS code. 

- What I don't know is, what happens to the GPIO settings for the debug interface after RSS code execution, when the boot continues. 

1. Debug GPIOs are still in reset setting (debug is possible, maybe I just missed the small time window until the exitSecureArea() is called)

2. Debug GPIOs are disabled after RSS code execution and must be enabled as well in bootloader. (Would be nice to know. I did not found any hints in the documentation.)

 

So I will make sure, the bootlader as well as the application does explicitly sets the debug pins. 

 

 

 

 

 

[Something0815]

Hello Jocelyn,

I did now tried to set the secure protection bits, which does not work via CubeProgrammer v2.15 and v2.10. 

_________________________________________________________________________

CubeProgrammer v2.15:
- SECURITY bit is set

- SEC_AREA_START1 to 0x000 

- SEC_AREA_START1 to 0xfff (same values to protect whole bank tested as well)

-DMES1 checked

 

-> no popup window

-> progress indicator does not stop (even after minutes)

-> output log on verbosity lvl 3 shows nothing

-> read the option bytes stops the indicator and reads the default setting

_________________________________________________________________________

 

CubeProgrammer v2.10:

- SECURITY bit is set

- SEC_AREA_START1 to 0x000 

- SEC_AREA_START1 to 0xfff (same values to protect whole bank tested as well)

-DMES1 checked

 

->  popup windows with warnings that we can do serious damage 

-> Error: Option Byte Programming failed 

-> see attached screenshot with log (Secure Protection level settings were set and now reset with the error pop up)

_________________________________________________________________________

st-link utility tool v4.6.0.0

-> "Internal command error" while opening the option bytes menu

-> It seems to read the correct values (security byte is set), but I did not tried to write the option bytes because of the internal error

________________________________________________________________________

 

Do you have any idea what causes this kind of error?

[Something0815]

Finally it worked after serveral retries with CubeProrgammer v2.10. Thanks for your help!