STM32F767 Change RDP level from second stage bootloader

[SGAUR.1]

Hello,

I have second stage bootloader in place and want to change RDP level from it (0 to 1 and roll back when doing firmware upgrade).

However, the problem is, once RDP level is changed to 1, bootloader is not able to change it back to 0. 

I've to change RDP level 0 from ST-link v2 and stm32cube programmer which results in mass erase of the chip (which ends up erasing my second stage bootloader).

Is there any way around it ?

My actual issue is : I want to disable read from mcu. Either through RDP or any other mechanism (which i'm not aware of at this moment).

Device : STM32F767

Thanks,

Shriram

#STM32F767 #RDP

[Peter BENSCH]

That would be like sawing off the branch you are sitting on. As RM0410 says:

When Level 1 is active, programming the protection option byte (RDP) to Level 0 causes the Flash memory and the backup SRAM to be mass-erased. As a result the user code area is cleared before the read protection is removed. The mass erase only erases the user code area. [...] Mass erase is performed only when Level 1 is active and Level 0 requested. When the protection level is increased (0->1, 1->2, 0->2) there is no mass erase.

Does it answer your question?

Regards
/Peter

[Bubbles]

Hi @SGAUR.1,

there's no way of lowering RDP level without mass erase.

To do firmware update in RDP1 or even RDP2, you just need to implement IAP - in-application programming - you can even call it a bootloader and have it work as a bootloader. It just needs to run from user flash memory.

Take a look here: X-CUBE-IAP-USART - STM32Cube in-application programming using the USART embedded software (AN4657) - STMicroelectronics

For more security I'd suggest considering X-CUBE-SBSFU - Secure boot & secure firmware update software expansion for STM32Cube - STMicroelectronics

BR,

J

[SGAUR.1]

Thank You for providing clarity on operation.

Is there any other way to disable read ?

 

Shriram

[Bubbles]

Hi @SGAUR.1,

there's also PCROP and MPU, both can be used to limit readability of the code. But keep in mind that flash can be also read during execution - compiler will create literal pools to optimize execution and mix them with code.

If you want to protect the SW IP as much as possible from prying eyes of the competition, you should have a look at the SBSFU project. When it's configured well, it provides reasonable protection. To step the IP protection even further, look at the STM32H5.

BR,

J

[Pavel A.]

Why do you want to disable read protection? Firmware update (flash writing) can be done even under RDP - by the firmware itself, of course.

[SGAUR.1]

Pavel,

Flash writing via custom boot-loader is not working if RDP is enabled (level 1 in my case), I tried this.
if you're talking about on-chip-system-bootloader, then yes, it's possible via that route. But this is not possible in my case due to custom bootloader.

If I'm missing something here, let me know. I open for suggestions/trials.

Thank you,

Shriram

[Pavel A.]

@SGAUR.1 This is very strange. RDP should not affect writing internal flash from inside (unless write-protected via option bytes and few other quirks)

[SGAUR.1]

Pavel,

You were right, RDP level 1 is not affecting writing flash from second stage bootloader. I was able to get it working.

Differences :
Previous set up :

• Bootloader code at power on checks for RDP level - if RDP is not set, set it to level 1
• program bootloader using st-link
• try to program application, doesn't work : I need to figure out why this code was creating issue.

objective here was to reduce dependency on mfg step and possible goof-up.

Working setup :

• I removed checking & setting RDP level 1 code from bootloader
• program bootloader from using st-link.
• set RDP to level 1 using st-link
• Programmed application as usual. No issues faced and MCU is read protected.

Thanks for your guidance.

Shriram

[Piranha]

• Bootloader code at power on checks for RDP level - if RDP is not set, set it to level 1
• program bootloader using st-link

With RDP above level 0 the debugger cannot program any memory, except option bytes at level 1. It's clearly written in a reference manual.