[STM32L4R5ZIT6 ]: STM will halt unless flashed even number of times

[Robin-OhPL]

Summary

• Flashing with st-flash or GDB load can halt the chip on odd-numbered flashes.
• Re-flashing or power cycling recovers the chip. Pressing reset does not help.
• STM32CubeProgrammer (GUI or CMD) does not show this issue.
• Core ID discrepancy suggests a potential STLink detection problem

---

Typically, we flash the new program onto the STM32L4R5ZIT6 with either a STLINK-V3SET or a STLINK-V3MINIE using one of two methods on a computer running native Ubuntu 22.04 :

1. Using make flash
   This is a wrapper that internally runs:

   st-flash --connect-under-reset --reset write $(BUILD_DIR)/$(TARGET).bin 0x8000000

2. Using GDB
   Start the debugging session with:

   st-util
   gdb-multiarch build/firmware.elf -ex="tar extended-remote :4242"

   Then, run load inside GDB to program the chip.

---

Observed Behavior

Whenever we use either of the above methods, the chip always halts if programmed an ODD number of times..

In GDB, the sequence looks like this:

Reset_Handler () at startup_stm32l4r5xx.s:91
91        str  r3, [r2]
(gdb) load
Loading section .isr_vector, size 0x1c0 lma 0x8000000
Loading section .text, size 0x16f10 lma 0x80001c0
Loading section .rodata, size 0x7a0 lma 0x80170d0
Loading section .ARM.extab, size 0x308 lma 0x8017870
Loading section .ARM, size 0x4f8 lma 0x8017b78
Loading section .init_array, size 0x18 lma 0x8018070
Loading section .fini_array, size 0x8 lma 0x8018088
Loading section .data, size 0x880 lma 0x8018090
Start address 0x08015cc8, load size 100624
Transfer rate: 27 KB/sec, 7740 bytes/write.
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x1fff51da in ?? ()
(gdb) bt
#0  0x1fff51da in ?? ()
#1  0xfffffffe in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) start
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Temporary breakpoint 1 at 0x8014a10: file Core/Src/main.cpp, line 178.
Note: automatically using hardware breakpoints for read-only addresses.
Starting program: /home/robin/Desktop/firmware/build/firmware.elf 
^C
Program received signal SIGTRAP, Trace/breakpoint trap.
0x1fff34c2 in ?? ()

---

Recovery Methods

Pressing the reset button does not resolve the issue. Currently, there are two ways to recover:

1. Re-flash the chip
   Flashing the program again allows the chip to run normally. Historically, we have always run load twice to mitigate this issue.

2. Power cycle
   Power cycling immediately after observing the issue also allows the chip to recover and run normally.

This indicates that the program is correctly flashed, but something unusual happens after the flash process.

---

Additional Observations

• This issue has persisted since the beginning of development back in 2023
• We suspect it may be related to stlink, as STM32CubeProgrammer (GUI or CLI) provided by STM does not exhibit this problem and stlink is an open source project and its not maintained by STM.
• The Core ID read by stlink-gui appears incorrect, It reports: 0x2BA0 1477. However, according to section 57.8.3 of RM0432 Rev 9 (Reference Manual, STM32L4+ Series advanced Arm® -based 32-bit MCUs) and the supported device list in your repo /stm.h, the correct Core ID should be: 0x1BA0 1477

Note: For some reasons, running st-info --probe does not return the core id and depending on the type of st-link in-circuit debugger/progammer used, chip id may get returned.

---

[Robin-OhPL]

Please let me know if any additional information is needed. Thank you so much in adavnce!

[Robin-OhPL]

Updated my stlink to version: v1.8.0-121-g8c34a4e. Still experiencing the exact same issue.
Previously using `v1.7.0.