Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Faster SWD by using SPI port #9

Open
MrZANE42 opened this issue Apr 13, 2021 · 10 comments
Open

Faster SWD by using SPI port #9

MrZANE42 opened this issue Apr 13, 2021 · 10 comments

Comments

@MrZANE42
Copy link

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
Copy link
Author

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

@UweBonnes
Copy link

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
Copy link
Author

MrZANE42 commented Aug 4, 2021

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
Copy link

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
Copy link
Author

MrZANE42 commented Aug 4, 2021

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
Copy link
Contributor

xobs commented Dec 29, 2021

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
Copy link

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

@xobs
Copy link
Contributor

xobs commented Dec 30, 2021

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
Copy link

peddamat commented Jan 6, 2023

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

@xobs
Copy link
Contributor

xobs commented Jan 6, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants