Giters

blackmagic-debug / blackmagic

In application debugger for ARM Cortex microcontrollers.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

BMDA's ST-Link backend cannot properly handle DPv2+ targets

dragonmux opened this issue · comments

commented

This issue is intended to track the progress of sorting the ST-Link BMDA backend out, which presently has a correctness issue that prevents it working with DPv2+ targets.

As noted in PR #1605, there is a crash that has not yet been addressed which manifests against multi-drop SWD parts as:

***  1   STM32H5 M33
Unhandled exception: ST-Link error
[1]    1801873 IOT instruction (core dumped)  src/blackmagic -s 0018003A544B -tv 1

which when expanded on, is caused by this interaction:

***  1   STM32H5 M33
stlink_adiv5_clear_error (protocol recovery: false)
 request: f2 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00
response: 80 00
Write TARGETSEL: 0x04740041
stlink_raw_access: Attempting access to addr 000c
 request: f2 46 ff ff 0c 00 41 00 74 04 00 00 00 00 00 00
response: 16 00
Unhandled exception: ST-Link error

This is because in the current implementation, TARGETSEL writes (and therefore multi-drop support) are broken due to invoking the wrong packet kind on the ST-Link v3. This doesn't show up on a v2, only v3. In part this is because we do not correctly implement line reset right now, or know of any specific method ST has provisioned for switching which DP we're talking to.

After talking this through with ALTracer on Discord he wound up doing some research which yields that doing a STLINK_DEBUG_EXIT followed by a STLINK_DEBUG_ENTER_SWD_NO_RESET does in fact generate a line reset (among other bits of interaction) which suggests a path forward that fixes at least protocol recovery which is also broken, as noted, due to stlink_adiv5_clear_error() not presently doing the right thing to clear the protocol error condition. We invite ALTracer to elaborate further on his findings below.

commented

Stlink firmware can not handle Multidrop, as does Cmsis Dap V1. So on startup, SWD Multidrop Scan is not called, but old SWD scan. So no target selection is done and there is no need to try to restore the target selection => Drop the try to restore target selection