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!

[MM..1]

---

@DAlbe.3 wrote:

  At this point, the uC frequently would not boot and would not even respond to a hard reset.  Only a power cycle clears this condition.

---

I work with many STM many years and AFTER activate RDP1 always required full power off. Simply by design.

[DAlbe.3]

All of our development units were built with rev Z chips (device ID 0x1001).
I will look through some other units.  If this is solved in newer versions, that would be great news.  I'll also check our stock and see if we have newer chips on hand...I think we have a few thousand of these.

As it is, with the rev Z chip, the option byte setting and RDP level 1 seem severely broken.
You can see from my last screenshot that you can indeed read OTP while RDP is set to level 1.

[DAlbe.3]

...and of course, all of our stock is rev Z. I just ordered some new parts from Digikey for delivery Monday; hopefully they will be the newer version and hopefully that works better than the rev Z parts.

[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.

[DAlbe.3]

The issue turned out to be errata 2.2.3 combined with a bad component that was preventing the workaround (disable  nBOOT_SEL in the option bits).

[DAlbe.3]

It turns out the OTP is expected to have read access under RDP level 1.
I think that's very undesirable and hope ST will change this in the future since OTP is the perfect place to store things like encryption keys, serial numbers, etc.
The table below is from RM0454 Rev 2:

[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

[waclawek.jan]

Thanks, @Jocelyn RICARD .

JW

[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.