STM32G030 readout protection level 1 (errata 2.2.3) POR lockup if boot select via BOOT0 pin enabled

[DAlbe.3]

EDITED:
Resolved, but leaving here for the next person who stumbles into this issue.
I'm using the STM32G030K6 and encountered two issues:

1. Errata 2.2.3 - which correctly describes a serious issue when using readout protection level 1: if nBOOT_SEL is not set in the option bits, the uC will often fail to boot and even a hard reset will not recover, only a power cycle.  The errata correctly describes a workaround: set nBOOT_SEL in the option bits (removes the option to force entry to the bootloader by tying the BOOT0 pin high).
2. Access to OTP memory is not protected by readout protection level 1.
   This is expected behavior since SystemMemory is not protected by RDP level 1, but it is unfortunate given that OTP is the perfect place to store device-specific persistent data like serial numbers, encryption keys, etc. This is particularly true on devices with limited flash where allocating a separate sector may be painful. Perhaps in a future version of the component, ST will consider protecting OTP as well as the code space.

The rest of this thread is obsolete, it was the result of a failed component where I could not set the nBOOT_SEL bit successfully.  Many thanks to @waclawek.jan for all of the patience and help!

[DAlbe.3]

Progress: I swapped out the chip on the unit I've been having trouble setting the nBOOT_SEL bit and now that piece is working!  So I now have a unit configured with RDP level=1 and the BOOT option bit set correctly and so far I have not been able to reproduce the failure-to-boot with this configuration.  I'll update again if I reproduce it, but I think my problem was a failed part...thank you so much for the help @waclawek.jan.

I think the only thing worth noting then is that with RDP level 1, the OTP memory is still accessible for read via STLink

 

I will change the title of this thread to indicate that and I'll test on a few more units; if I can't reproduce the problem, I'll mark this closed.

[waclawek.jan]

Thanks for coming back with the solution. Please click on "Accept as solution" in that post so that the thread is marked as solved.

I wonder what caused the problematic nBOOT_SEL option bit. It can't be wear, as the inverted value is always matching the "straight" one, even after the surprising change during powerdown.

I have doubts about the OTP lock and start a separate thread to ask ST for comment, as it is a separate problem from this (btw. have a look at the table you've posted, in the newest revision of RM0454 - it differs exactly in this detail).

JW

[Jocelyn RICARD]

Hello @DAlbe.3 ,

I confirm OTP value can be read in RDP1 on STM32G0. I checked on few different G0 part numbers.

I will raise the point internally to get the RM fixed.

Best regards

Jocelyn

[DAlbe.3]

Thank you Jocelyn. There are probably multiple documents that need correction; for example, see slide 8 here:
https://www.st.com/content/ccc/resource/training/technical/product_training/group0/68/e5/5c/b5/40/10/43/22/STM32G0-Security-Memories-Protections-MEMPROTECT/files/STM32G0-Security-Memories-Protections-MEMPROTECT.pdf/_jcr_content/translations/en.STM32G0-Security-Memories-Protections-MEMPROTECT.pdf

If there is ever a silicon revision of the STM32G0, I think it would be better to make the silicon match the documentation and protect OTP when RDP is set to readout protection level 1.  I can think of very few cases where the current behavior is what developers would desire or expect.  OTP would be dramatically more useful if you could secure data stored there.

[Jocelyn RICARD]

Hello @DAlbe.3 ,

I agree there is an issue in the documentation.

Now regarding the actual protection of OTP value, I don't think this is an issue.

OTP are One Time Programmable and are not erased on RDP regression.

So, protecting OTP while in RDP1 does not bring you any OTP confidentiality protection as long as you can regress the device to RDP0 and read the OTP in clear.

Here, OTP purpose is to ensure immutability of the data, not confidentiality 

If you need this confidentiality, you must use RDP2. In that case, it you need to update the firmware, you will need a secure boot and loader in user flash to make sure a fake firmware cannot be installed.

Best regards

Jocelyn

[waclawek.jan]

Thanks, @Jocelyn RICARD .

JW

[wangxl]

Thank you! I've encountered the very same problem with STM32G030F6P6. Setting nBOOT_SEL option works for me.

I would like to add some hardware details about the issue I encountered. This problem is highly related to the power supply. On my PCB, there is a 470uF capacitor. When the system powers on, if this capacitor is fully discharged, the STM32 fails to start. However, if the capacitor has a small residual voltage (> 0.xV), the STM32 starts normally.

I used an oscilloscope to check the VCC voltage rise curves in both cases, and I didn’t find obvious differences.