Feature: Alternate Manchester SWO implementation using DMA

[ssimek]

Fast DMA-based TRACESWO Manchester decoding

Detailed description

The current interrupt-based TRACESWO decoding suffers (IMO) from several issues

• it is limited to ~100 kHz (~50 kbit/s raw, i.e. ~25 kbit/s decoded SWO console) signal
  • while this is usually sufficient for text-based debug output, it gets worse when more data needs to be sent out/graphed/etc
  • it also unnecessarily impacts performance of the tested code, because the MCU has to wait for the ITM to be available
• high frequency hangs the probe due to an overload of interrupt requests
  • this happens easily when starting with new hardware before the init code is debugged

This PR contains a full reimplementation of the TRACESWO link decoder using DMA that makes capture a lot more efficient:

1. all edge times of the signal are captured using a timer
2. DMA is used to record the timings into a circular buffer
3. the buffer is periodically processed in batches, transformig the edge stream into a byte stream for sending in another circular buffer, resulting in effective processing time per sample on the order of several clock cycles
4. the output buffer is processed in a lower-priority ISR as time permits

The result is the ability to process SWO signal up to ~3 MHz with the probe being more resilient against higher frequency signals (it just fails to decode it properly). Continuous streaming at these speeds obviously makes USB a bottleneck (1.5 Mbit = ~180 kB/s, with the USB controller seemingly being able to handle up to about 70 kB/s without double buffering). But for reasonably intermittent flows, one big benefit is the lightened load on the target.

Your checklist for this pull request

• [x] I've read the Code of Conduct
• [x] I've read the guidelines for contributing to this repository
• [ ] It builds for hardware native (see Building the firmware)
  • it does, but it doesn't fit, neither did the original one, at least not with GCC 13.3 I'm using - it fits with LTO, but then the GDB server doesn't work for some reason. I was developing it with a few targets removed so it fit
• [ ] It builds as BMDA (see Building the BMDA)
  • not applicable, the only change is for the native hardware
• [x] I've tested it to the best of my ability
• [x] My commit messages provide a useful short description of what the commits do

Closing issues

None that I'm aware of

[dragonmux]

Before we review this, please adjust all the nomenclature etc over to the current state of things - the pin is technically called TRACESWO in exactly one place in the CoreSight TRM, however it is referred to as SWO everywhere else including all the Architecture Reference Manuals so BMD takes the opinion that we should be consistent and use SWO only to refer to it to make sure nobody gets confused with parallel Trace.

Additionally, the file should be named for which encoding mode it implements - so, in this case.. swo_manchester_dma.c. This code likewise seems to take the old SWO init interface, please use and obey the current API given this also needs a way to be deinitialised and the pin returned back to use as TDO on most probes. The SWO_PIN and SWO_PORT macros exist for switching the pin over to the right mode for the decoder.

Also note that trace_buf_drain was entirely replaced with a routine that is interrupt safe, and that all the buffering for this was lifted out of the backends, simplifying them, the API, etc.

Once you have adjusted things for the current API, please run clang-format on your contribution as it contains many formatting errors.

Finally, we are retargeting this to main as this change will not be landing on the v1.10 firmware branch. That branch exists for bugfixes not features.

[ssimek]

Making this PR against 1.10 was fully intentional since main has diverged significantly and seems to be unfortunately quite unstable and under heavy development. If there's not going to be another 1.x release (the nature and cadency of changes in main has a very 2.0-ish vibe to it), I'm ok with maintaining this in my own fork for my own use for now. Once there is a stable release based on current main, I'll look into adjusting the code to the new standards.

[dragonmux]

main should be stable, and if it is not for your target(s), we need to know please - open bug reports, tell us, that's how we get to know that something broke. The issue with Flash size will be addressed in the next couple of weeks as the firmware build is going to be split into target profiles. It is at this point seeing minor features only and bugfixes pending a v2.0 release candidate.

The SWO engine was entirely overhauled as it was entirely broken on GD32F1-based BMPs, and the buffer management rewritten so it does something more useful for both SWO modes + so the pin could be properly returned back to use for JTAG after as this is a bug in the v1.x firmware series. The new code should be considered stable pending any show-stopping bugs that require any more rework.

It's not so much that there won't be another v1.x release, so much as that branch is specifically for bugfixes backported from main, so unless a major bug were found in v1.10 there is unlikely to be another v1.10 release and if there was it would only be for a bugfix, not a feature. The release branches are always specifically for this purpose only.

[ssimek]

I understand. I'll try to find the time to give 2.0 another chance - it may have been just bad luck, but the main I originally checked out about a week ago had issues with SWO, buffering, etc. (various artifacts appearing in the stream even in low speed scenarios) so I chose to base my work on the stable branch. In case it is stable enough for daily use, I'll port the changes and reopen this PR.

[ssimek]

Created #1960 for the 2.0 implementation