Can we get SWD support?

[ghost]

Is that possible while only using FOSS?

[whitequark]

There is already a (preview quality) SWD applet! There's no actual gdbserver (or flasher) support right now mostly because I was going to integrate with @azonenberg's jtaghal, and jtaghal isn't evolving quite quickly enough. There will likely be native gdbserver support, the same as for MIPS EJTAG applet.

[esden]

You might be able to plug it into https://github.com/orbcode/orbuculum

[whitequark]

That's mostly pointless, it's just more C code I cannot actually distribute with Glasgow itself... Really, the protocol is not very complex.

[whitequark]

Update: I will not even try to rely on jtaghal, Glasgow-native gdbserver is superior in every way.

[JustAnother1]

I have done some work on SWD. Please let me know how I can help realize the SWD support.

[whitequark]

There's a prototype of an SWD applet. What's missing is the actual debugger code. Currently the bottleneck is maintainer time / review bandwidth so there is little you can do to make things faster.

[samlittlewood]

I have been picking at SWIM+stm8, programming only so far.

[whitequark]

We should probably have a different issue for SWIM, as far as I remember it's a completely different protocol.

[samlittlewood]

Certainly! I have a couple more branches from master for other protocols, but they are pretty gross atm. I'll create merge rqs when that have at least some utility.

[wrongbaud]

Is it worth trying to write a driver for support with openocd? That's something I've done in the past and would be willing to work on.

[whitequark]

Does openocd have something like the JTAG bitbang interface but for SWD? Anything that works through a socket rather than through libusb would work.

[wrongbaud]

I believe so - I can start experimenting with this and report back if I find something.

[whitequark]

We can quite easily add a swd-openocd applet like the existing jtag-openocd one, yep.

[perigoso]

i never realized there was a jtag-openocd bridge, what are the limitations of it? how fast can the clock go? one of the things i wanted from the glasgow was to use it as a debugger programmer

[whitequark]

As fast as the native JTAG applet allows, which is currently 6 MHz due to a temporary limitation while we're migrating from Migen to nMigen.

[perigoso]

in that case that swd-openocd applet could prove real usefull to me, how far away in the horizon do you see that coming? not asking for a timeline, just a ballpark.

[whitequark]

No idea if OpenOCD can even do the equivalent of that. @wrongbaud may be investigating that; you could take a look too if you want things earlier.

[perigoso]

I have every intention of helping, especially on matters that are especially useful to me; I will look into it, though i am not very familiar with the inner workings of openocd. Also my glasgow is just a parts bin waiting to be assembled so i can't test anything.

[perigoso]

So, i looked around the OpenOCD code. Apparently, as it is right now, the remote_bitbang driver that is used with the jtag-openocd applet only supports JTAG, though i found two unmerged patches that added SWD support, i have no idea why they were left open, but they were trivial changes and if they actually worked it shouldn't be to hard to convince them to push them upstream, i have already opened a ticket asking about it. That being said, if the remote_bitbang supported SWD, not much would be needed in the glasgow applet side in order for it to work, am i correct?

[whitequark]

That being said, if the remote_bitbang supported SWD, not much would be needed in the glasgow applet side in order for it to work, am i correct?

Correct.

[perigoso]

So, after opening the ticket there was some progress, one of the patches was rebased, but it needs to be tested, i cant do it myself, because my glasgow isn't ready, and i don't know how i could do it any other way.

If someone could look into this it would be great, i believe it should work.

Here's the ticket: https://sourceforge.net/p/openocd/tickets/269/

[electroniceel]

If someone could look into this it would be great, i believe it should work.

I have a working Glasgow revC1 and would like to help, but I haven't used OpenOCD for some time. So what exactly should I do to test?

Take a recent OpenOCD and apply http://openocd.zylin.com/#/c/4205/ But what would be the next steps to get it running?

I have for example a STM32F072 and would hook up it's SWCLK and SWDIO to the Glasgow.

[FFY00]

I think you just need to add the new commands to JTAGOpenOCDSubtarget and then you should be able to get glasgow to open a server, as shown in https://github.com/GlasgowEmbedded/glasgow/blob/8a277fe9bd609e9abfa8d3b526f95f7c4cdeeac9/software/glasgow/applet/interface/jtag_openocd/__init__.py#L71, and invoke openocd with the stm32f0x config.

Should look something like this:

openocd -c 'interface remote_bitbang; remote_bitbang_port 2222' -f /usr/share/openocd/scripts/target/stm32f0x.cfg

[whitequark]

I don't think that would work, JTAGOpenOCDApplet can't electrically do SWD if I remember correctly.

[FFY00]

Hum, okay. Then we can just copy it to a new applet and apply the required modifications.

[perigoso]

I believe connecting to a target using SWD and that driver should be enough to approve the changes.

I don't think we actually need to change anything in the applet.

[FFY00]

Well, you should need to test if the new commands actually work, no?

[perigoso]

hm, i don't think i understood quite right how the applet worked, i guess you're right

[whitequark]

We now have swd-openocd. I'm going to close this issue since it does enable SWD debugging and it'll likely be quite a while before I have bandwidth to either implement or review support for ADIv5 (including internal architecture changes needed to make it maintainable).