Potential regression in hosted mode bluepill->bluepill

[mean00]

Hi
While updating my local copy , i noticed a potential issue
How to reproduce :

1- Connect BMP running on a bluepill to another blupill
Load a random blink.elf sw directly (gdb->/dev/ttyACMx)
It works

2- Now go through hosted mode, using the same sw and the same BMP host built from the same source, running on the same bluepill
( updated 10mn ago to be sure it was not transient, _v1.9.0-693-g6c193f06) )

load blink.elf
The memcompare fails for every block written

Section .text, range 0x8000000 -- 0x8004750: MIS-MATCHED!
Section .ARM.exidx, range 0x8004750 -- 0x8004758: MIS-MATCHED!
Section .data, range 0x8004758 -- 0x80047a0: MIS-MATCHED!
Section .rodata, range 0x80047a0 -- 0x8004d1c: MIS-MATCHED!
Section LNVECTOR, range 0x8004e00 -- 0x8004f30: MIS-MATCHED!

Indeed, The flash has been erased but not written

Additionaly, the hosted bmp sw is complaining

scan_multidrop: false
remote_v3_adiv5_mem_write_bytes error around 0x08000000
remote_v3_adiv5_mem_write_bytes error around 0x08000400
remote_v3_adiv5_mem_write_bytes error around 0x08000800
remote_v3_adiv5_mem_write_bytes error around 0x08000c00
remote_v3_adiv5_mem_write_bytes error around 0x08001000
remote_v3_adiv5_mem_write_bytes error around 0x08001400
remote_v3_adiv5_mem_write_bytes error around 0x08001800

NB: It works with RP2040 target
It seems to work if the same BMP sw is running on a bluepill and the target is a rp2040, both in direct and in hosted mode.

It used to work a couple of months back with the same setup

Sorry for the noise if it is pbcak

[dragonmux]

Could you please get a log of BMDA running src/blackmagic -v 13 > stm32f1-bmda-bmp.log and post that on this issue report as this looks like a bug in the v3 remote protocol implementation, possibly introduced with #1459 which overhauled that system.

That should allow us to figure out what exactly's going wrong to analyse this and come up with a fix.

[mean00]

Please find the log file attached
Thank you
stm32f103-bdma-bmp.log

[mean00]

I did a bit of bissection (it is not accurate but may help) :
a3aa29c => works
6730405 => does not work

[dragonmux]

Please find the log file attached

Thank you very much!

Thank you
stm32f103-bdma-bmp.log

Unfortunately, while this helps a lot in figuring out what was going on, we goofed on what verbosity level to request - sorry to ask if you could re-capture the log changing -v 13 to -v 29 which will enable additional diagnostics and complete tracing of the remote protocol interactions

The bisection helps narrow down what set of changes could have caused this regression :) We suspect it's something we did during the remote protocol overhaul, but this helps figure that out

[mean00]

Please find attached the log using -v 29
Thank you
stm32f1-bmda-bmp-v29.log

[jcw]

FWIW: same here. As a workaround, I can get re-flash going ("most of the time") by keeping the target reset button pressed until the upload wants to start (I'm using PlatformIO, so it's all hidden behind a layer of Python). The build log shows:

CURRENT: upload_protocol = blackmagic
MethodWrapper(["upload"], [".pio/build/fork/firmware.elf"])
Auto-detected: /dev/cu.usbmodem80A978D61
arm-none-eabi-gdb -nx --batch -ex "target extended-remote /dev/cu.usbmodem80A978D61" -ex "monitor swdp_scan" -ex "attach 1" -ex load -ex compare-sections -ex kill .pio/build/fork/firmware.elf

(to clarify: the app being uploaded is called "fork", and this is on macOS)

When connecting manually with gdb, "mon sw" (i.e. "monitor swdp_scan") fails. It's all slightly erratic, perhaps timing?

[dragonmux]

Sorry it's been so long getting back to you about this, @mean00! We started trying to dive the logs you so kindly provided, but they appear to be truncated slightly (not your fault) as the error that caused the remote_v3_adiv5_mem_write_bytes error around 0x08000000 lines was not getting reported and logged. We've addressed this on the branch fix/bmda-improved-remote-protocol-error-handling, so please give that branch a try using -v 61 as the logging level and let us know how you get on please.

From the data available, it looks like a firmware remote protocol bug but till we get a bit more data from the remote protocol transactions we cannot tell the nature of the bug.

[mean00]

Confirmed to be fixed, thanks & sorry for the slow reply

[dragonmux]

No worries, thank you for getting back to us to confirm that!