BSbsder·May 12, 2025
> I allow for the possibility that SWD is far more complex than I imagine, but this approach works pretty well for figuring out whats going on with SPI or I2C or BLE.
SWD is pretty well documented. I won't claim its simple, but, in my opinion, it's decent at what it does. The RISC-V folks haven't seemed to be able to do better (and, IMO, did quite a bit worse in a few places, actually).
The SWD description at the packet/command level:
https://arm-software.github.io/CMSIS-DAP/latest/index.html
There is open source code directly from ARM for it:
https://github.com/ARMmbed/DAPLink/tree/main/source/daplink/...
The documentation of the actual wire protocol is also extensive, but a little more scattered:
https://developer.arm.com/documentation/ihi0031/a?lang=en
https://community.nxp.com/pwmxy87654/attachments/pwmxy87654/...
The big problem wi
Read the rest
th the SWD wire protocol ARM documentation (and everybody who copies it) is that they don't point out the fact that when you go from Write-to-Read the active edge of the clock changes. In SPI-speak, you switch from CPHA=1 to CPHA=0. This makes sense if you stop to think about it for a moment because during debug there is no clock. Consequently, SWD must provide the clock and you switch from "put something on DATA a half phase early->pulse clock to make chip do something with it" to "pulse clock which makes chip put something on Data->read it a half phase later". However, if it has never been pointed out to you before, it's likely to trip you up.
Sigrok (or similar) which can decode SWD properly and a digital signal analyzer (even a cheap $10 one) are your friends.
The only diagrams which seem to resemble scope traces that point this out are on obscure Chinese engineering blogs.