SWD protocol - talk to BangleJS 2 over cable

Hello, this is a followup to this post https://forum.espruino.com/conversations­/378217/#16732065

SWD protocol is typically used to debug software running on ARM Cortex-M CPUs however it can be also easily used for just doing direct access to memory (RAM, internal flash).

Bangle 2 has SWD debug pins routed to USB data pins of charging cable so with some extra software and hardware this can be used for talking to Bangle 2 over cable.

SWD uses 2 pins similar to I2c or bidirectional SPI and the protocol is relatively simple.
Best introduction I found is here http://markding.github.io/swd_programing­_sram/
Full docs including PDF download https://developer.arm.com/documentation/­ihi0031/a?lang=en

I wrote initial prototype of basic memory read/write over SWD here
https://github.com/fanoush/EspruinoBoard­s/blob/master/STLINKV2/swd.js
I am using STLink V2 clone dongle running Espruino but it should be usable on any ARM based Espruino device with 2 GPIOs available.

For now I can power up/down the interface and read/write memory

basic usage is

swd_setup(clkPin, dioPin)
swd_init().toString(16) // should print 2ba01477 for cortex M3/4 targets
dap_poweron() // powers up MEM-AP
readmem32(0x10001014) // should print bootloader address of nrf52 in UICR

So far there are some small optimizations for speed - for sending 8 or 32 bits shiftOut is used, for receiving of 32 bits software SPI is used (just clk and miso, spi mode 2 seems to work). Unfortunately the protocol is not aligned to byte boundary due to 3bit ACK response in the middle and parity bit in the end so those extra bits are sent by toggling gpios directly.

Next step is allocating some memory buffer on target device with some signature header (like Segger RTT does) and searching for it over SWD and passing blocks of data over it in both directions.

One goal is to use any espruino with USB or serial to act as serial to SWD adapter to have Espruino console (and WebIDE) running over it via WebSerial in Chrome.

Thats very neat -will it be fast enough to use for loading code into flash?

The swd in nrf52 is designed for up to 8MHz https://devzone.nordicsemi.com/f/nordic-­q-a/54961/nrf52840-programming-speed , typically SWD dongles use 1MHz, limit is probably also related to wire length. I did not see issues previously with bangle2/Q3 charging cable and SWD dongles used with openocd running at 1MHz. The overhead of the protocol is 14 extra bits with each 32bit transfer https://github.com/MarkDing/swd_programi­ng_sram#32-successful-transaction-operat­ion , when reading/writing in automatic incremental mode just one packet is needed to send/receive next 32bit value.

Of course the software must match the speed. Also from initial testing I see the MEM-AP transfer from memory produce some initial timeouts - not sure how many of those there will be when pushing the interface to maximum. When CPU is not stopped the transfer shares the AHB bus with code that is running and needs to use RAM/flash for that , see picture at https://infocenter.nordicsemi.com/topic/­com.nordic.infocenter.nrf52832.ps.v1.1/d­if.html?cp=4_2_0_15#debugandtrace

Not sure if any of that answered the question, though ;-)

Direct writing to (internal) flash over SWD can be either done by toggling flash NVMC registers directly or another way that openocd is using is to upload some flashing code stub to ram then just send data block to ram and let the CPU do the flashing. However I suppose the easiest way is to make espruino console working over SWD and then push data over it.

This looks really exciting!

One goal is to use any espruino with USB or serial to act as serial to SWD adapter to have Espruino console (and WebIDE) running over it via WebSerial in Chrome.

That would be great! I guess it's even possible that things like ESP8266/ESP32 could expose it over wifi too.

This opens a bunch of possibilities, and not just for serial... I really liked the idea of being able to control external hardware from the Bangle's pins on the back - but I guess a super cheap micro would be able to handle polling/writing via SWD and then setting up GPIO accordingly.

I should add that I think recently some mbed-compatible SWD programmers (inc micro:bit?) started shipping with 'Web USB' compatible firmware. So that could be an option as well to handle the PC->SWD side (although it's not as cool as this).