Enabling PCROP with RDP level 0 causes board to crash
Hello,
I have an unexpected behavior with a H753ZI board. After a very few steps, I ended up in a situation where PCROP seems to be enabled and RDP level is set to 0. For some reasons, this causes the board to freeze indefinitely, moreover after disconnecting it, it became unresponsive to any action using STM32CubeProgrammer or ST Link Utility.
The symptoms:
- The board can not be connected to in a mode other than "hot plug" mode. Trying to connect in "normal" mode yields the error DEV_TARGET_NOT_HALTED. Trying to connect to the board using the "under reset" mode while holding the reset button down does not work either. This has been tried using STM32CubeProgrammer, ST Link Utility and STM32 Programmer CLI.
- Once connected in "hot plug" mode, full chip erase is impossible. An error is given saying "Error: Mass erase operation failed.Please verify flash protection".
- In "hot plug" mode, I am also unable to modify any of the option bytes. For example, if I try to set the RDP level from 0 to 1, I get the error "Error: Expected value for Option Byte "RDP": 0xBB, found: 0xAA".
- RDP level is locked to 0 and DMEP1 and DMEP2 option bytes are disabled (and cannot be modified). The start and end addresses of the PCROP flash banks also became immutable.
How I ended up here:
- I loaded a test code of my own on the board in debug mode. A code that I know works and never caused any issues.
- I wanted to ensure PCROP protections to be disabled. Therefore I applied the following steps as I knew PCROP would be disabled if RDP level is switched from 1 to 0 with DMEP1 bit enabled and end address greater than start address for the PCROP flash bank 1 (same analogously for the second bank with DMEP2).
- I switched RDP level from 0 to 1 and applied the changes.
- I enabled DMEP1 and DMEP2 and applied the changes.
- I switched RDP level back from 1 to 0 and applied the changes.
- I disconnected the board.
Since then, the behavior I described before happened and I could not find any way to recover the board in a programmable state. Did I unknowingly follow a sequence of manipulations that set the board in a dead state ? I am still a novice with STM32 products so I may very much have.
Any suggestions are welcome, I am completely out of ideas and desperate. I don't even know how I ended up in such a situation that easily.
