Content originally posted in LPCWare by majbthrd on Sun Jul 21 12:53:34 MST 2013
I have an LPC-Link 2 with the CMSIS-DAP firmware.
Periodically, it stops working and the only solution is to unplug it and plug it back it.
I probed the SWD pins when it stopped working, and noticed that SWDIO was stuck high.
Looking at the Keil/ARM code for the LPC-Link 2 (or at least what parts of it I could find online), it looks like there is an implementation bug in the CMSIS-DAP firmware.
DAP_SETUP() and PIN_SWDIO_OUT_ENABLE() are LPC-Link 2 macros that turn on drive for SWDIO. SWDIO_OUT_DISABLE() turns drive off.
DAP_SETUP() must get called at reset. PIN_SWDIO_OUT_ENABLE() and SWDIO_OUT_DISABLE() get called in the function SWD_Transfer##speed().
The problem is that not all execution paths in SWD_Transfer##speed() leave SWDIO_OUT in the same state. If SWD_Transfer##speed() returns after calling SWDIO_OUT_DISABLE (such as might happen after the target device fails to ACK any transfer), SWDIO is stuck off!!!
When subsequent SWD_Transfer##speed() calls happens, the code tries to transmit bits, but it will always fail because SWDIO_OUT is disabled.
Recovery requires resetting (which means unplugging the power to the LPC-Link 2).
Another possible kludgy workaround is to for the host to issue a DAP_Disconnect command. This would take advantage of yet another bug in the LPC-Link 2 driver code. The PORT_OFF() macro is supposed to turn off SWDIO_OUT, but instead it turns it on! :( I don't want to recommend this approach, as it DEPENDS on a bug, and that is another bug that should be fixed.
Perhaps NXP can fix the firmware and issue an update? Users are powerless to do this themselves because there is no complete source code, it depends on a proprietary tool chain, and the board uses a pre-production undocumented microcontroller (LPC4370).
