Faster SWD by using SPI port

[MrZANE42]

Don't know if you've seen this. https://www.pcbway.com/blog/technology/OpenOCD_on_Raspberry_Pi__Better_with_SWD_on_SPI.html
It's for the OpenOCD codebase but the underlying SWD 'bus' is the same so the same should be possible using an ESP8266 instead of an raspberry pi. It might be quite some work to get up and running so I understand if it won't be implemented.
Just wanted to let you know if you needed an interesting challenge ;-)

[MrZANE42]

https://community.st.com/s/question/0D50X0000BmnMM5/stm32-use-spi-implement-swd

[UweBonnes]

Can the ESP32 do SPI from 1 to at least 8 bits. Then doing SWD should be doable. Otherwise fast bitbanging can also get you a long way.

[MrZANE42]

According to the page below it seems like it should be possible to send/receive 'frames' that are shorter than 8 bits.
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/peripherals/spi_master.html

[UweBonnes]

The page tells: "The Device will still receive 8 bits with 3 additional “random” bits, so the reading must be performed correctly." Random bits in a strict protocol are not good ;-(

[MrZANE42]

My take away from that is that it will just shift in the number of bits requested and the data in register for the other bits are to be considered random.

[xobs]

FYI: I've been porting this to ESP32, and I've moved to using the SPI driver. My implementation is up at xobs@f386d25 and currently suffers from a number of problems:

1. It doesn't tristate the bus afterwards, meaning both the SWD device and BMP drive the bus.
2. There are very long pauses between SPI transactions, and I currently do two transactions when transmitting or receiving parity bits. This adds a lot of overhead.
3. The speed is hardcoded to 5 MHz currently.

These are not insurmountable problems, and I intend to rewrite the SPI interface so that it uses lower-level constructs rather than the Espressif drivers, which do a lot of locking, unlocking, and allocating.

I believe when it says that it will receive additional "random" bits, what it means is that it inhibits the SPI_CLK line output but the SPI block still clocks in those bits. As a result, the additional bits are effectively don't care. That is, if you ask it to read 3 bits of data, then you'll get 3 bits of good data and 5 bits of garbage. Which is fine, you were going to ignore the garbage data anyway, just mask it off. Plus it's probably 0 anyway.

So far I've managed to communicate with a SAMD09 board via an ESP32 using this setup. I've dumped memory, done a mass_erase, and restored flash. So in my very limited testing this approach seems viable, and much more reliable than the bit-bang approach.

[UweBonnes]

I do not understand why a bitbang approach should be less reliable.

[xobs]

I'm not sure. It felt like a pulse synchronizer issue that I was running into on ESP32 where GPIO inputs and outputs weren't synchronized despite the presence of memw, wherein reads to a GPIO bank were returned before the bit actually reached the pin. The memw instruction just ensures that the memory access has reached the IO_MUX block, but it doesn't ensure that bit has made its way out to the real world.

There's also the issue of disabling interrupts, which seems like it can adversely impact wifi on the single-core ESP8266. Using SPI would mean avoiding the need to disable interrupts, which should give you more reliable networking.

[peddamat]

@xobs Appreciate both of your efforts, just wanted to make sure you’d seen this: https://github.com/flipperdevices/blackmagic-esp32-s2

[xobs]

I hadn't seen that -- it's very handy, and I might take their SPI code.