-
-
Notifications
You must be signed in to change notification settings - Fork 775
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
Feature: Alternate Manchester SWO implementation using DMA #1958
Conversation
* Try to print extended capabilities. If the adapter doesn't advertise support for them, then just print standard capabilities, like it was before.
…l byte * According to Wireshark usbmon dumps, the firmware returns 112 bytes of version, including some copyright information after an effectively 0-terminator. * Use strchr() instead of index() for Windows reasons. * Make sure the version buffer contains at least one NULL * And avoid replacing the only NULL with LF, losing null-termination in the process
* Asking for 1 byte less raises a libusb OVERFLOW error when using JLink V8 and newer with BMDA on Linux hosts after the proprietary software stack touches the adapter (but not before). * libusb docs recommend receiving into a bigger buffer (1028=512*2+4) and checking whether all of expected data got indeed received. * For firmwares which send that transaction-error byte in a separate packet, keep the second read call (V5 ones do this regardless).
… which would make wrongly it skip chunks of the buffer to write, corrupting the message to send
* Add a reduced loop like the one in bmp_poll_loop(), allowing BMP to service GDB accessing syscall buffers in target memory; * Use both F-reply and Detach as exit conditions, passing a corresponding result code for the target to see when we resume it
…lise the packet data in shifting
DFU detach wasn't lowering the USB pullup. This meant that BMP was rebooting into DFU bootloader mode, but the host wasn't re-enumerating it, because it hadn't detected a detach. In `platform_request_boot`, The `gpio_set_mode` config was for analog instead of floating input. PA8 isn't defined as an analog pin on this chip, so it's arguably undefined behavior. Also confirmed that using `scb_reset_system` instead of `scb_reset_core` to do the DFU reboot would correctly detach and enter the bootloader, if the boot button was held down.
Fix two problems with SWD turnaround: * When going from output to input, add a missing delay loop, so the clock low period is consistent. This prevents problems with a missed clock edge when the clock speed is intentionally slowed to accommodate lower bandwidth connections to the target. * Always set the clock low at the end of a turnaround. Otherwise, when floating the clock after a read transaction, the most recent clock state was driven high. If there's a pull down on the clock, a subsequent clock reactivation would drive the clock high, producing an extra rising clock edge. This sometimes causes (recoverable) protocol error states when re-attaching after a detach. Co-Authored-By: Stanislav Sotnikov <[email protected]>
Add missing idle cycles after SWD read transactions. ADIv5 (ARM IHI0031G) §B4.1.1 requires at least 8 idle cycles after any SWD transaction (not just write transactions) before stopping the clock. This does add some delays to read transactions where there were previously none. A future change could conditionally disable the idle cycles for both read and write transactions if it is known that a new transaction will immediately follow.
…itch, where a threshold violation is detected during normal operation. Now we need to count 3 threshold violations to trigger the protection mechanism.
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.. 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 Finally, we are retargeting this to |
Making this PR against |
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 |
I understand. I'll try to find the time to give 2.0 another chance - it may have been just bad luck, but the |
Created #1960 for the 2.0 implementation |
Fast DMA-based TRACESWO Manchester decoding
Detailed description
The current interrupt-based TRACESWO decoding suffers (IMO) from several issues
This PR contains a full reimplementation of the TRACESWO link decoder using DMA that makes capture a lot more efficient:
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
Closing issues
None that I'm aware of