Skip to main content
Associate II
April 8, 2024
Solved

STM32G031C6 problems during production programming

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

 

 

 

 

This topic has been closed for replies.
Andreas Bolsch
Andreas BolschBest answer
Lead III
April 9, 2024

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.

 

6 replies

Tesla DeLorean
Guru
April 8, 2024

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

 

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
TFBorthAuthor
Associate II
April 8, 2024

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
Andreas BolschBest answer
Lead III
April 9, 2024

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.

 

TFBorthAuthor
Associate II
April 9, 2024

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

TFBorth_0-1712677650846.png

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

Andreas Bolsch
Lead III
April 9, 2024

ES0487 - Rev 6 - September 2023, 2.2.9

TFBorthAuthor
Associate II
April 9, 2024

Thank's!

I've just found at ES0418 from STM32G031:

TFBorth_0-1712679187391.pngTFBorth_1-1712679213374.png

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