Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dragonmux opened this issue May 3, 2024 · 1 comment
Open

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

dragonmux opened this issue May 3, 2024 · 1 comment
Labels
BMD App Black Magic Debug App (aka. PC hosted) (not firmware) Bug Confirmed bug

Comments

@dragonmux
Copy link
Member

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.

@dragonmux dragonmux added Bug Confirmed bug BMD App Black Magic Debug App (aka. PC hosted) (not firmware) labels May 3, 2024
@UweBonnes
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
BMD App Black Magic Debug App (aka. PC hosted) (not firmware) Bug Confirmed bug
Projects
None yet
Development

No branches or pull requests

2 participants