| > 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 with 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. |