STM32G031C6 problems during production programming

[TFBorth]

Dear all,

In the last weeks we have started the production process of a specific equipment, using the new microcontroller STM32G031C6 and unfortunettly we have faced some problems after the programming process.

The problem is that some devices were apparently corrupted by removing programmer cable before disconnecting the microcontroller (or because a bad connection) and there is no way to recover them.

This is the logging information of Jlink programmer:

Connecting ...

- Connecting via USB to probe/ programmer device 0

- Probe/ Programmer firmware: J-Link Ultra V4 compiled Sep 22 2022 15:00:10

- Probe/ Programmer S/N: 504502941

- Device "STM32G031C6" selected.

- Target interface speed: 4000 kHz (Fixed)

- VTarget = 3.323V

- InitTarget() start

- SWD selected. Executing JTAG -> SWD switching sequence.

- Error: Failed to initialized DAP.

- Can not attach to CPU. Trying connect under reset.

- SWD selected. Executing JTAG -> SWD switching sequence.

- Error: Failed to initialized DAP.

- Connecting to CPU via connect under reset failed.

- InitTarget() end

- Took 441ms -

- ERROR: Failed to connect. Could not establish a connection to target.

An important feature is that the source code is enabling Read Protection Level 1.
Other important information is that we are used to manufacturer other products using STM32F0 and STM32F4 and we never faced a situation like that.

We also have tried using JLink and ST-Link, but nothing change. Programming pins are exclusive (not used as GPIO) and once microcontroller is replaced, programming process is done without issues.

Anys suggestion?

Regards,

Tiago F. Borth

[Tesla DeLorean]

RPL1 shouldn't preclude access by the debugger

Does the code check for the integrity of the entire firmware image before engaging RPL1 ?

Any Option Bytes changed?

NRST connected to the debugger?

Can you get to BOOT0 pins

[TFBorth]

Does the code check for the integrity of the entire firmware image before engaging RPL1 ?
No

Any Option Bytes changed?
No

NRST connected to the debugger?
Yes

Can you get to BOOT0 pins
Boot0 pin is shared with SWDCLK pin, I've trie to connect a 10K PD resistor but no response.

[Andreas Bolsch · Accepted solution]

---

An important feature is that the source code is enabling Read Protection Level 1.

---

Don't do that! Changing RDP level does in fact erase the whole option byte block and then rewrites this block with the current settings from flash registers. Probably your target software is intended to increase RDP level upon first start? If this start happens right after flashing the firmware, any glitch (power supply, NRST line, ...) at that time may cause invalid/unwanted option bytes setting. Errata sheet, 2.2.11, says that lockup should not occur anymore on rev. "Y", but there are probably more ways an improper setting might cause trouble.

So either let the programmer do the RDP level change, or let the programmer start the firmware which reprograms the option bytes and does an option byte load, and wait for confirmation of successful completion before disconnecting the programmer.

[TFBorth]

Thanks Andreas, I've just found this information at STM32G031 Reference Manual:

Just one question, which Errata are you referring to exactly?

[Andreas Bolsch]

ES0487 - Rev 6 - September 2023, 2.2.9

[TFBorth]

Thank's!

I've just found at ES0418 from STM32G031:

This is the real problem that has benn occurred...