STM32G030 corrupting program on last minute write

[Hendrik1]

I have a STM32G030K8 processor that needs to write some stuff to memory as soon as it detects that it will be losing power - always a bad time but I have to do this.

Most of the time it seems to be doing this just fine but once in a while the processor gets corrupted.

Here is the problem though, I have write protected the code space and the only pages not write protected are two pages at the end of memory where I want to write the data to. During stable operation I erase these pages, so that at last minute I just have to write the data.

The problem is that the actual program gets corrupted in the write protected pages.

Does write protection only affect external writing or also internal writing? In other words, is it a possibility that the write instructions leave the entire memory vulnerable for corruption even though I am not altering the write protection on the pages with program code in?

[waclawek.jan]

Enable Brown-out reset in the Option bytes.

JW

[Hendrik1]

How would that affect the problem of the actual code getting corrupted. After code corruption with the final write the controller is unable to execute the program anymore.

[waclawek.jan]

I mean, enable Brown-out reset in the Option bytes, when you first program the mcu.

It remains to be enabled, and upon power going down, holds the mcu in reset, preventing the programming hardware to fail, when supply voltage falls below the threshold where it stops working correctly.

JW

[Hendrik1]

Okay, I see what you are saying. Thanks, I will give it a try.

[Hendrik1]

It appears that the device does not have a select-able BOR. It is always present and as such, this does not seem to be an option.

[waclawek.jan]

Can you check the value at address 0x1FFF7800?

JW

[Hendrik1]

I have done a bit of digging yesterday. Unlike the STM32G0X1 series, the G0X0 series does not have a "published" controllable BOR system. For the G030 the option bits are "reserved". Reading the option byte always returns the "reserved" BOREN bit as set on a new device. As for the level bits, they are also reserved but can be set - I have not tested if changing these bits are functionally working the same as the G0X1 series voltage levels. In other words, it might be there or might not, but it is not published.

I have however found a typo in my code. I loaded the option byte in my code with:

0000 1101 1111 1111 1110 0001 0000 0000 instead of

1101 1111 1111 1111 1110 0001 0000 0000

Now in theory that should make the unit boot from system rather than main memory and that might have caused a problem.

Reading the option bytes back though always return the correct value 1101 1111 1111 1111 1110 0001 0000 0000, so obviously some other stuff going on in the hardware

[MM..1]

How you predict stable operation for erase ? Erase cost big time and you require stable power for this.

Idea with detect power loss = power go down ... Only safe way is switch to some backup capacitor on detect or detect on primary bigger voltage ...

---

@Hendrik1 wrote:

During stable operation I erase ...

---

 

[Hendrik1]

Hi MM; I consider stable power to be when I have got both a mains supply (AC) power as well as a battery supply of above 10V present. The emergency state write happens when I have a loss of AC and the battery voltage drops below 10V. On a battery disconnect the voltage could however drop very rapidly so I also have a 1000uF cap on the 3V3 line to just hang onto power a tad longer.

[MM..1]

This all is very simple checked with scoped minimum two signals : 3V3 on MCU and power loss detector or some input power. Optimal is place into code after flash store gpio toggle and on thirdth channel scope this pin...

Show this image and will see

[waclawek.jan]

This is then disconcerting, but at this point the only thing I can say is, that you have to make sure all erasing/programming finishes until VDD drops below the brownout level (2.1V).

JW