pyOCD Raspberry Pi GPIO probe driver

[amitchone]

Hi there,

I'm currently using OpenOCD on a Raspberry Pi to program an STM32L0. I've written a basic Python wrapper around OpenOCD as a quick fix. I'm wondering if there are any examples or documented uses of using pyOCD with the native SWD (BCM18, 24 and 25) pins available on a Raspberry Pi?

Thanks, Adam

[flit]

Hi @amitchone. pyOCD doesn't currently have a probe driver for RasPi SWD, but it would be nice to have. I will transform this issue into a feature request.

I don't know too much about the RasPi board or pins. Are those SWD pins you mention hooked up to the GPIO connnector? Are they just regular GPIO or something special? Thanks!

[amitchone]

Hey @flit. They are indeed broken out on the GPIO header - see here. The header breaks out full JTAG and SWD. When using OpenOCD the driver of choice is the "GPIO JTAG/SWD bitbang driver" so I assume there's no JTAG specific hardware under the hood. I believe they are just regular 3V3 GPIOs with nothing special under the hood - don't quote me on that.

I'd be more than happy to help implement the feature if needs be!

[flit]

My interpretation of your comment plus the diagram is that the JTAG pins are are for debugging the RasPi itself. For driving SWD/JTAG to debug another chip, you can probably use any available GPIO.

I'd be very happy to have a RasPi GPIO driver for pyOCD! Definitely would need some help implementing it, though. 😄

[flit]

There is already a bit of an SWD bit sequence generator at https://github.com/flit/pyOCD/blob/feature/jlink/pyocd/probe/jlink/swd.py, plus a bitstring class in that folder. (This was written for an attempt to add driver-less JLink support, before I realized that was a bad idea and if I add JLink support it should be through the standard driver and pylink project.)

I'll be more than happy to create the skeleton for the debug probe driver.

[cederom]

You may want to take a look at my LibSWD project that I did around 2010 to create first free and open source platform independent framework to work with SWD from DAP/AP operations down to bitstream used by GPIO.. feel free to use it if that comes handy anyhow :-)

http://www.libswd.com https://github.com/CeDeROM/LibSWD

[40Grit]

Off topic,

I still think SWD emulation via FTDI is something that needs more research.

I was pretty darn sure openOCD supported it.

[cederom]

Hey @40Grit it is possible to craft all SWD packets with LibSWD on GPIO and FTDI. I have created a simple driver to use LibSWD with KT-LINK (FTDI2232-H chip) :-)

LibSWD support can be added to pyOCD in order to provide such GPIO and FTDI (maybe others too) connectivity. If anyone feels it could be useful here I can make it. It is on purpose created as library under BSD license to make this possible :-)

This LibSWD + OpenOCD integratio was done and working around 2013 but then it was not accepted into the master because "it was not a community project".. this is why I have stopped using and developing OpenOCD ;-) Here seems to be a someone's fork of my works on GitHub:

https://github.com/corecode/openocd-libswd

One important note: GPIO performance may be sufficiently fast, but FTDI performance really had this USB latency bottleneck and you cannot really make anything about that even with asynchronous LibUSB it uses separate commands to read/write bytestream to/from FTDI and each SWD transaction has several ones. FTDI performance is nothing compared to DAPLink+GPIO+FlashAlgo. Also FlashAlgo uses on-chip injected code from RAM in order to perform Flash Writes in a DMA-like manner. Those Flash Writes at low-level over SWDP<->AP are a far more complicated and far more slower because you need to talk directly to the Flash Controller Block and you cannot simply use CPU code that writes to a memory (anyways I did that on some STM32 chips + simple Debug with absolutely no CPU code).

Conclusion: GPIO driver in best case scenario should act as "Software-DAPLink" and it will always outperform FTDI-like drivers in orders of magnitude :-)

[flit]

@40Grit Yes, I agree. Back we FTDI was last discussed, I even bought an FTDI breakout cable to be able to develop and test it. However, it's quite low priority. It's something that's much more likely to happen if a contributor writes it. 😉

@cederom There's no reason you can't use the same RAM-resident flash algo method with FTDI.

Btw, I was well aware of your libswd quite a while before I met you! 😄 In the case of pyOCD, I think I'd rather have the SWD and JTAG sequencing written in Python in order to reduce binary dependencies. (But there's a good argument for having a pure-Python version of libswd, or wrap it with a Python API.)

[amitchone]

@flit If you're happy to put together a skeleton for an RPi debug probe driver I'm sure I can cobble something together, using the other probes as an example. I've a few references for SWD bitbang drivers so should be able to get something fairly sensible up and running.

[flit]

@amitchone Deal. It's on my todo list. I'll reply here when it's ready. (See the link in my comment above for existing SWD code I wrote for pyocd.)

[amitchone]

@flit Lovely stuff, speak soon!

[oholimoli]

@amitchone is your solution with OpenOCD on the RPi here on GitHub available?

[flit]

It's been a while… but there is now a standalone debug probe plugin that can be used as an example: https://github.com/pyocd/pyocd-pemicro.

Actually, since February, plugin support is new. So a RPi probe driver can be developed as a separate Python package, like the PEMicro plugin (which is separate partly because it allows the plugin to only have to support Python 3). Though I still would like to have it be part of the pyOCD org.

The PEMicro plugin will eventually be added as a dependency to pyOCD itself, so users don't have to manually install it. The same could be done with a RPi plugin if it makes sense.

[raffi-g]

Hi @flit and @amitchone I just wanted to ask, whether there is any development on this issue.

[flit]

Not that I'm aware of.

[heezes]

@flit Any plans on adding Raspberry Pi debug probe support?

[flit]

Yes, actually. 😄 I even got a Blinkenlabs JTAG-Hat recently to make it easier to work on. However, there are a lot of competing priorities for pyocd, so it's not clear when I will get to it. Help from the community would certainly speed things up. 😉

Btw, the picoprobe plugin that is in the main pyocd repo is a better reference example than the pyocd-pemicro probe plugin mentioned above, since it generates SWD sequences like the RPi probe plugin will need to.

[diazmanuel]

@flit do you have any news about pyocd supporting raspi gpio for programing ?

[flit]

No, sorry. I haven't had any time to work on it! There are just too many things to work on. It wouldn't be too hard if someone wants to pick it up.