Non standard behavior of PCROP area, upon lowering RDP level in STM32G0B1RE

[jmir]

I have the following flash protections requirements:

1) Write protect the last sector (with start address 0x0803F800)
2) Read protect the entire flash with Level 1.
3) If the read protect is lowered, the data in the last sector must be unchanged.

I'm performing the following operations in a chronological order:

1) Program a proprietary bootloader and do a soft reset.
2) Enable single bank operation (DUAL_BANK=0) and do a soft reset.
3) Program the application and do a soft reset.
4) Program the last sector with data and do a soft reset.
5) Write protect the last sector (WRP1A_END=0x7F) and do a soft reset.
6) Set PCROP area that covers the last sector (PCROP1A_STRT=0x1FC and PCROP1A_END=0x1FD) and do a soft reset.
7) Increase read protection level from 0 to 1 (RDP=0xBB)
8) Power cycle the device (POR is performed)

After this, I reduce the RDP level from 0 to 1 and, when checking the data integrity of the last sector, I verify that the entire sector was set to zeros. The sector is not erased, as expected based on the table bellow (reference manual in page 89, table 19) nor maintains its data integrity, which violates my requirement - 3) If the read protect is lowered, the data in the last sector must be unchanged.

Notes:
1) PCROP_RDP is set to 0.
2) I tried other PCROP areas where PCROP_START and PCROP_END are in different pages but had the same result (PCROP_START=0x1fb and PCROP_END=0x1ff).

[Pavel A.]

How do you verify the integrity of the PCROP area? By definition, it cannot be read. It is execute-only.

[Danish1]

ST’s Flash Readout Protection applies to the entire chip. And they make lowering readout protection erase the entire chip.

If lowering Flash readout protection didn’t do a full erase then it would be easy to overcome.

Could you expand on why you want to be able to go from readout-protected to unprotected.

If you want to be able to learn what’s in some of the Flash e.g. to check the version number of the code, or maybe read out things that your code writes to flash such as a diagnostic log, could you implement a command that sends that information through e.g. a UART. Ok it won’t be as easy to read out as using Stm32CubeIDE, but it means that you get to choose which parts of Flash may be read and which not.

[Pavel A.]

@Danish1 The PCROP protected area(s) are excluded from mass erase, if some option bit is set. Likely, this is what the OP wants.

But, in case mass erase worked, the erased flash should read as all FFs. The OP says it reads as 0. This hints that the PCROP area indeed has survived RDP regression.

[jmir]

I tried to read the region I protected with STM32Programmer and observed unprotected areas with FF and the protected one with 00.

The functional goal I want to achieve is to have device data (like serial number) persistently stored, even if someone tries to "hack" the flash by revert the RDP option bit. Achievable with OTP but I need something reversible due to manufacturing details.

[jmir]

The functional goal I want to achieve is to have device data (like serial number) persistently stored, even if someone tries to "hack" the flash by revert the RDP option bit. Achievable with OTP but I need something reversible due to manufacturing details.

[Pavel A.]

> The functional goal I want to achieve is to have device data (like serial number) persistently stored

Fine. So you've already considered RDP and found it not suitable. OK.

You can get the data stored in the PCROP area with the common PCROP trick: call a function inside the PCROP area, which will return the data in registers or RAM. The function should be written in a special weird manner, because the flash in the PCROP area is not readable, even by code that runs in that area.