Enabling SBSFU security flags cripples my code

[MHoss.1]

I've ported the SBSFU package for my user app. It works great when only read out protection is enabled. Everything works as it supposed to. However, when I activate other security flags random errors/problems arise in the code. For example, when I activate the PCROP, a timer based PWM stops working. I'm using HAL library for this PWM so I'm not sure how the error might come from my code.

	TIM_OC_InitTypeDef sConfigOC;
	sConfigOC.OCMode = TIM_OCMODE_PWM1;
	sConfigOC.Pulse = (uint32_t)dCycle*10; // 1000 count PWM timer
	sConfigOC.OCPolarity = TIM_OCPOLARITY_HIGH;
	sConfigOC.OCFastMode = TIM_OCFAST_DISABLE;
	HAL_TIM_PWM_ConfigChannel(hboard.release_tim, &sConfigOC, TIM_CHANNEL_1);
	HAL_TIM_PWM_Start(hboard.release_tim, TIM_CHANNEL_1);

I've had trouble with other security flags too. For example when I activated MPU_USERAPP my user app starts started to consistently crash with hard faults in a module so I deactivated it. The funny thing is that after some development on other parts of my code, I can activate this flag now without any hard faults.

I am not sure what is the source of these problems but I sure want to take care of them. I would appreciate any guidance.

[Jocelyn RICARD]

Hello MHoss,

Did you make any change in the SBSFU mapping?

Regarding PCROP, normally it impact only a flash part you never access. So, this behaviour is not expected at all !

About MPU, hardfault is the normal behaviour when MPU is not properly setup.

If you have a hardfault here, this means that you try to access to a memory region you are not allowed to.

After a porting, any change in the mapping requires MPU setup change.

You have some details on this topic in the integration guide (AN5056).

Best regards

Jocelyn

[MHoss.1]

I did change the code sections a little bit so as you say the MPU part is expected. Thank you for pointing me in the right direction.

For the PCROP, AN5056 says it is automatically computed based on the SBSFU linker symbols, also I should say that my code does not fill all the dedicated space in the flash. I'm pretty sure I don't use direct addresses anywhere in the code to access any illegal address in the flash but I double check that. For the sake of debugging, let's assume the code tries to access something out of the flash bounds, should it crash the program instead of a peripheral not working? I had no idea how to go deeper from here as the PWM function was from ST and we had busy days but I would be following up if you can think of a suspicious point.

[Jocelyn RICARD]

One first thing to check when activating PCROP is the actual PCROP programmation in option bytes. It should only cover the flash area dedicated to the keys.

Just use STM32CubeProgrammer to read option bytes.

[MHoss.1]

Sorry to get back to you late. The start of the PCROP is aligned, the end is 7 bytes shorter than what the linker files sets (actual value is 0xf8, the linker asks for 0xff). I think this means parts of the keys are not protected but it's not advancing into other sections.

[Jocelyn RICARD]

Hi MHoss,

I'm sorry I don't catch your point.

Anyway an easy way to check the PCROP area is to connect the STM32CubeProgrammer for instance and read the content of the flash.

You will see where it stops.

Best regards

Jocelyn

[MHoss.1]

Yeah I checked it through CubeProgrammer, maybe easier to make it like a table

___________________| Start address | End address

linker _____________| 0x______400 | 0x______4FF

CubeProgrammer | 0x______400 | 0x______4F8

[Jocelyn RICARD]

Hello,

well if your question is about the difference between the end address in the linker file and end address of the PCROP configuration option bytes, the reason is that PCROP configuration is aligned on double word. This means that configuration register will contain this ...4F8 instead of ...4FF

The data you put in this area can reach ...4FF and will still be protected by PCROP setup with ...4F8.

I hope this answers your question

Best regards

Jocelyn

[MHoss.1]

@Jocelyn RICARD​ The question is why activating PCROP causes the timer to not work, you asked me to check the actual PCROP range compared with the value calculated in the linker file and I reported the values.

[Jocelyn RICARD]

Hello,

well, PCROP is "just" a memory protection. You cannot read not write in the defined area.

So, I can't see why it could impact the behaviour of your timer.

What I would do it use debugger and capture the Timer and GPIO registers configuration with and without PCROP enabled to check if there is a difference.

If no difference, l will need your porting to try to reproduce on my side.

Best regards

Jocelyn