You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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
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:
which when expanded on, is caused by this interaction:
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 aSTLINK_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 tostlink_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.The text was updated successfully, but these errors were encountered: