cancel
Showing results for 
Search instead for 
Did you mean: 

Device no longer boots after setting RDP = 1

brohr01
Associate III

Hello,
I have written a custom bootloader for my stm32u5 project and have been testing it for the last few months with multiple working firmware updates.  To give some context, I transfer an encrypted firmware image to an external flash chip over CANfd from the currently running firmware.  The next time the device boots, the bootloader looks for a new encrypted image on the external flash and if found it will decrypt the image, delete the internal flash where the application lives and then flashes the decrypted image. It will then de-init some peripherals and jump to the new application, fairly standard implementation.  All of this has been working flawless until I set RDP = 1(DC) in stm32cubeprog.  Also need to mention that I have set both passwords for RDP regression a while ago, I just have not been setting the RDP level beyond 0.

With RDP = 1 the device will boot as it should, and I can send it a firmware update.  I will power cycle the device and it will perform the firmware update as it should. Everything appears to work as it should, every call to HAL_FLASHEx_Erase and HAL_FLASH_Program return HAL_OK during the update.  However it does not successfully jump to / run the new application, the power draw of the device goes down to the same level as a halted device. 

It appears as if the flash is not being erased, in my bootloader I performed a read after a page erase and it was not 0xFFFFFFFF.  What is preventing an erase with RDP enabled that would otherwise work correctly?

 

3 REPLIES 3
Jocelyn RICARD
ST Employee

Hello @brohr01 ,

The only reason a code can fail to run in RDP1 (if RDP1 is the only difference with non-failing case) is the usage of debug related feature.

When RDP Level1 is enabled the debug related IPs are disabled.

The usual feature concerned is the cycle counter DWT_CYCCNTR that is used for short delays.

Best regards

Jocelyn

 

Thank you for your response.  I have not enabled DWT CYCCNTR unless threadx, usbx or anything else I am using has enabled it.  I do have SWD w/ trace enabled for the project, do I need to disable those in the IOC file before building the release firmware to be used?

Jocelyn RICARD
ST Employee

Hello @brohr01 ,

Yes the SWD trace may be detected as an intrusion resulting in CPU stall.  You can try removing this trace. No need to disable with IOC, just comment the call to ITM_SendChar for rapid check.

Best regards

Jocelyn