Closed ALTracer closed 3 months ago
(it still uses traceswoasync.c which you touched in at least PR555)
Actually any probes implementing either Manchester or UART will post the decode mask, this was introduced in https://github.com/blackmagic-debug/blackmagic/pull/664 , so before v1.7.0; now that I think about it, I often build firmware with ENABLE_DEBUG=1
to diagnose issues within it, and I successfully fixed a couple of them that way. You can see a debug_en
in logs in mon help
response. But in current BMD codebase these lines seem to not be gated on ENABLE_DEBUG anymore, and I don't know how to git annotate
for that without total git grep
.
I don't have screenshots, but I got a "Trace setup problem (error 8:0)" triggering in my message. Drivers may or may not have been installed, I use a slightly patched upstream blackmagic.inf with Rev_0109 to correspond with new descriptors (which pack MS BOS anyway). I could unplug tear down everything hidden/unplugged and Zadig them again, if needed; but the error message didn't lead me to think about it then.
Thanks. I'll consider this closed (and reopen in case I'll have a proper bugreport with logs etc.) There is a misphrasing in code comments from my side, but it doesn't affect operation.
Current state of things (v1.10 and 2024 main): BMP native
and BMP-compatibles support Manchester XOR UART, not both. Manchester doesn't need baudrate (and doesn't parse it / doesn't consume extraneous parameters), UART needs it (or uses #define SWO_DEFAULT_BAUD 2250000
). All BMP-compatible platforms have ITM decode capability, and will indicate which of 32 channels they'll parse and print over ttyBmpTarg -- this is not coupled to capture engine flavour (and present even in your v1.7-fork).
In the near future it might be refactored to parse parameters differently, and to include both engines, but no ETAs on that.
Summary
Using either binaries for Windows from 2023-03 (1.4.6918), or building bmdebug suite myself in 2023-11 (1.2.6986), I get the error on trying to use bmtrace with probes running recent firmware. https://github.com/compuphase/Black-Magic-Probe-Book/blob/531cf0488aa6cdebd7bff78d4939378d393670db/source/bmp-support.c#L1324
Description
Since PR1137 https://github.com/blackmagic-debug/blackmagic/pull/1137 the upstream has changed format of remote monitor responses for
traceswo
command. Existing code in bmp-support.c does not expect this and returns early, failing to detect the Trace USB endpoint number.Initially I wanted to use the Orbuculum suite to test my experimental changes of reshuffling EP numbers for
blackpill-f411ce
platform, but it FTBFS on Windows 10 under MSYS2 UCRT64 (gcc throws -Werror=format etc. from libdwarf dependency code). So I remembered the other, closer to BMP ecosystem, software stack and tried the binaries with no result. Cloning and building that yielded a different error message, so I opened the logs & sources and started hacking.Because my change remaps TRACE_ENDPOINT from 0x85 to 0x83 (anything above EP 3 does not exist in f411 dwc2 usbotg IP, and it just does not respond to IN tokens at all), I had to change the default definition both in orbtraceIf.c and in bmp-scan.h; but I noticed some code which tries to parse a live GDB RSP BMP response in an older format. Unfortunately, I also noticed that current BMP answers with a hardcoded "...EP 5\n" string (PR pending).
A related issue is that after my patching, bmtrace on Windows 10 fails harder with a yet another error message I traced down to https://github.com/compuphase/Black-Magic-Probe-Book/blob/531cf0488aa6cdebd7bff78d4939378d393670db/source/bmtrace.c#L1049 with loc_errno=8 from https://github.com/compuphase/Black-Magic-Probe-Book/blob/531cf0488aa6cdebd7bff78d4939378d393670db/source/swotrace.c#L877 ; if this is best posted separately, then I'll stop discussing it and wait for you to fix it on your machine instead. Only
blackpill-f411ce
does this;swlink
firmware on a genuine stm32f103cbt6 bluepill works and bmtrace opens the trace port. Maybe it's the unreachable endpoints, maybe it's Windows Registry junk. You seem to walk the registry to get a DeviceInterfaceGUIDs and that key is missing from the relevant Interface (not Endpoint). I did not change interfaces in firmware.I will post some patch hunks, not expecting to get them accepted into any sort of PR whatsoever, and gdb-rsp.log excerpts I found after launching bmtrace.exe with f411 and swlink respectively. If you don't support upstream changes which break your code as the consumer of unspoken API, then we could at least negotiate with upstream on what format to print the messages in BMP firmware. For example, I don't quite like consecutive 32
o0
packets either. If your desktop software only supports adapter firmware built from your own BMD fork, then that should be stated in program help and maybe in the book. Just FYI, both BMDebug and BMSerial work fine with v1.10.0 recent release, as far as I briefly tested.