Truncated register 17 in remote 'g' packet

[Azq2]

Platform: bluepill (PROBE_HOST=stlink BLUEPILL=1)
Target microcontroller: stm32f030x4

Fresh BMP firmware randomly hangs with this error:

INSTALL /dev/serial/by-id/usb-Black_Magic_Debug_Black_Magic_Probe__ST-Link_v2__v1.9.0-rc0-11-g5ac4378b-dirty_C0D5DBD2-if00 stm32f0-pmic-with-rtc.elf (flash)
arm-none-eabi-gdb -nx --batch \
	-ex 'target extended-remote /dev/serial/by-id/usb-Black_Magic_Debug_Black_Magic_Probe__ST-Link_v2__v1.9.0-rc0-11-g5ac4378b-dirty_C0D5DBD2-if00' \
	-x bmp.scr \
	stm32f0-pmic-with-rtc.elf
blocking_handler () at lib/libopencm3/lib/stm32/f0/../../cm3/vector.c:104
104		while (1);
Target voltage: 3.27V
You are now detached from the previous target.
Available Targets:
No. Att Driver
 1      STM32F03 M0
A program is being debugged already.  Kill it? (y or n) [answered Y; input not from terminal]
bmp.scr:5: Error in sourced command file:
Truncated register 17 in remote 'g' packet
[Inferior 1 (Remote target) detached]
make: *** [Makefile:46: install] Error 1

And not responding anymore:

INSTALL /dev/serial/by-id/usb-Black_Magic_Debug_Black_Magic_Probe__ST-Link_v2__v1.9.0-rc0-11-g5ac4378b-dirty_C0D5DBD2-if00 stm32f0-pmic-with-rtc.elf (flash)
arm-none-eabi-gdb -nx --batch \
	-ex 'target extended-remote /dev/serial/by-id/usb-Black_Magic_Debug_Black_Magic_Probe__ST-Link_v2__v1.9.0-rc0-11-g5ac4378b-dirty_C0D5DBD2-if00' \
	-x bmp.scr \
	stm32f0-pmic-with-rtc.elf
Ignoring packet error, continuing...

• After repluging BMP all works fine for some time.
• USART (ttyACM1) also not working after this error
• I'm stable reproduce this error after 3-4 "load" commands. My gdb script:

monitor swdp_scan
attach 1
load
kill

[Azq2]

blocking_handler () at ../../cm3/vector.c:104
104		while (1);
(gdb) bt
#0  blocking_handler () at ../../cm3/vector.c:104
#1  <signal handler called>
#2  0x08014d4e in _malloc_r ()
#3  0x080155ba in _svfprintf_r ()
#4  0x080153ce in _vasprintf_r ()
#5  0x080071aa in gdb_putpacket_f (fmt=0x8018710 "T%02X") at gdb_packet.c:233
#6  0x0800695c in gdb_main_loop (tc=0x54415d25, tc@entry=0x20000008 <gdb_controller>, in_syscall=in_syscall@entry=false) at gdb_main.c:251
#7  0x08006d6c in gdb_main () at gdb_main.c:700
#8  0x08009528 in main (argc=<optimized out>, argv=<optimized out>) at main.c:44
(gdb) 

[Azq2]

$ arm-none-eabi-gdb -v
GNU gdb (GNU Arm Embedded Toolchain 10.3-2021.10) 10.2.90.20210621-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[Azq2]

Previous firmware on my BMP (0c639030) works fine

[Azq2]

I'm enable monitor debug_bmp enable, but don't see any logs when hangs. Only last success flashing:

scan_multidrop: false
DP DPIDR 0x0bb11477 (v1 MINDP rev0) designer 0x43b partno 0xbb
RESET_SEQ failed
AP   0: IDR=04770021 CFG=00000000 BASE=e00ff003 CSW=03000040 (AHB-AP var2 rev0)
Halt via DHCSR: success 02000003 after 0ms
ROM: Table BASE=0xe00ff000 SYSMEM=0x00000001, Manufacturer  20 Partno 440
0 0xe000e000: Generic IP component - Cortex-M0 SCS (System Control Space) (PIDR = 0x00000004000bb008  DEVTYPE = 0x00 ARCHID = 0x0000)
-> cortexm_probe
CPUID 0x410cc200 (M0 var 0 rev 0)
1 0xe0001000: Generic IP component - Cortex-M0 DWT (Data Watchpoint and Trace) (PIDR = 0x00000004000bb00a  DEVTYPE = 0x00 ARCHID = 0x0000)
2 0xe0002000: Generic IP component - Cortex-M0 BPU (Breakpoint Unit) (PIDR = 0x00000004000bb00b  DEVTYPE = 0x00 ARCHID = 0x0000)
ROM: Table END

[Azq2]

Hmmm.... on v1.8.2 works fine.

[dragonmux]

Thank you for reporting this issue. The GDB output you provided from doing Black Magic Inception suggests that your probe is running out of free heap space. Unfortunately, bluepill is not a probe host we have to test against (we only try not to break it), and our current internet connectivity issues make tracking this down harder too.

The commit ID you gave for a previously working version appears not to be a release but rather v1.7.1-232-g0c6390307, can you confirm this?

We will look into the F0 series support and check for things like spurious leaked allocations. It is in our interests to try and figure out a fix for this in time for v1.9-rc1. In the mean time, our request for some additional data using BMDA and current main firmware applies please as the enhanced log might shed some additional light on where the firmware is dying and why.

Bluepill having such limited RAM seems to make it very sensitive to memory exhaustion issues not seen on, eg, native, which would explain why this has been noticed only so late in the development cycle.

[Azq2]

Yes, it just random commit which I'm use in the past. I wrote it only for proof is problem of blackmagic, not my environment.

What logs you want? Of course, I not reproducing this bug on hosted blackmagic, but here logs from few flashings.
blackmagic2.log