STM32F44 MCU: Read protection flag not removed
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-15 2:49 AM
Hi
I try to implement the read protection on my STM32F44 board based on this example:
https://community.st.com/t5/stm32-mcus/how-to-change-the-read-out-protection-on-stm32f4/ta-p/49410
In principle, it works, but I have some strange behavior. My code:
if (level == 0x00 || level == 0x01) {
FLASH_OBProgramInitTypeDef pOBInit = { 0 };
HAL_FLASHEx_OBGetConfig(&pOBInit);
pOBInit.Banks = FLASH_BANK_1;
pOBInit.OptionType = OPTIONBYTE_RDP;
if (level == 0x00) {
new_level = OB_RDP_LEVEL_0;
}
else {
new_level = OB_RDP_LEVEL_1;
}
if (new_level != pOBInit.RDPLevel) {
do {
//Unlock flash
status = HAL_FLASH_Unlock();
//Unlock flash option sections
status = HAL_FLASH_OB_Unlock();
pOBInit.RDPLevel = new_level;
status = HAL_FLASHEx_OBProgram(&pOBInit);
//Triggers a reset
status = HAL_FLASH_OB_Launch();
HAL_FLASH_OB_Lock();
HAL_FLASH_Lock();
printLogWarning(halToCANxError(status), "Writing flash read protection failed");
return 0;
} while (0);
//Something failed, flash maybe already unlocked
HAL_FLASH_OB_Lock();
HAL_FLASH_Lock();
}
}
Two points are not working as they should:
- When I enable the read protection: As far as I understood, HAL_FLASH_OB_Launch() should trigger a reset. This works when I'm using the debugger. Without debugger, the warning message after HAL_FLASH_OB_Launch() is sent, it seems that these lines are executed. But the read protection is enabled afterwards.
- When I remove the read protection (Level 0): The flash is erased as planned. However, when I try to reprogram the device, there is still a message that the device is read protected. It seems that the flag was not reset correctly.
Any idea what I can do to solve these issues, especially the second?
Thank you.
Solved! Go to Solution.
- Labels:
-
STM32F4 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-15 3:29 AM
Hello @Corono ,
if the reset is done while the flash memory is not fully erased the RDP level will stay in level one this is explained in the example your trying to execute :
"if you reset the microcontroller before the FLASH memory is fully erased the RDP byte will stay locked at Level 1 and your program will be deleted, so it is very important so stand still while the FLASH is being mass erased."
so make sure you wait the appropriate time which can take upward of 20 Seconds . also don't forget to remove the CN2 connection of the STlink as referred in the example and after that you can check if the RDP level is set by reconnecting the jumpers and connecting via CubeProgrammer to verify .
BR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-15 3:07 AM
I solved the second problem. Because the reset didn't work correctly, I added a manual reset (not in the code above). However, it seems that the MCU was reset to early and the flag was not removed properly. If I remove the manual reset, disabling works.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-15 3:29 AM
Hello @Corono ,
if the reset is done while the flash memory is not fully erased the RDP level will stay in level one this is explained in the example your trying to execute :
"if you reset the microcontroller before the FLASH memory is fully erased the RDP byte will stay locked at Level 1 and your program will be deleted, so it is very important so stand still while the FLASH is being mass erased."
so make sure you wait the appropriate time which can take upward of 20 Seconds . also don't forget to remove the CN2 connection of the STlink as referred in the example and after that you can check if the RDP level is set by reconnecting the jumpers and connecting via CubeProgrammer to verify .
BR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-15 5:17 AM
Thank you for your answer. Understood.
For me, the behavior of the function "HAL_FLASH_OB_Launch()" is still a bit strange. What I observed:
- When the level is changed from 1 to 0, execution of the code stops after HAL_FLASH_OB_Launch() (which makes somehow sense because the memory is going to be deleted)
- When the level is changed from 0 to 1 and the debugger is connected, execution of the code stops after HAL_FLASH_OB_Launch() (which makes somehow sense because the debugger connection is directly affected by the change)
- When the level is changed from 0 to 1 (without debugger), execution of the code does NOT stop after HAL_FLASH_OB_Launch()
However, I can handle this in the code and the module is not reset.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-15 6:06 AM
Hello @Corono ,
how can you confirm that code execution in not stopped after HAL_FLASH_OB_Launch() in the level changed from 0 to 1 (without debugger) case ? this should not be possible because as you said this should trigger the flash erase process so i want to know how you identified that the code is still working .
BR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-11-15 7:43 AM
A change from OB_RDP_LEVEL_1 to OB_RDP_LEVEL_0 triggers the flash erase, not the other way around.
A change from OB_RDP_LEVEL_0 to OB_RDP_LEVEL_1 enables the read protection. In this case (without debugger), there is no restart. I have a log message after HAL_FLASH_OB_Launch() and this message is sent. And the module stays in operation and is responding to commands it wouldn't after a restart.
