Support for ctxLink Wireless debug probe
sidprice opened this issue · 6 comments
ctxLink is a wireless debug probe recently funded through Crowd Supply. I would like your utilities to support a network connection to the built-in GDB server and to the SWO data, when that is implemented in the probe.
If you can advise the best way to implement this in the tools I can look at it and see if I can generate a PR for this support.
@sidprice Support for the USB connection should be fairly easy. I think that it will be sufficient to change the routines in bmp-scan.c to detect the VID:PID of ctxLink (in addition to those of the Black Magic Probe).
Network support will require:
- Implementation of the GDB-MI ("machine interface") over TCP/IP (in addition to serial) for BMFlash and BMTrace.
- Likewise, capture SWOTRACE packets from a TCP/IP link (in addition to the current USB interface).
- Adaption of the parameters to the "target extended-remote" command in BMDebug.
- Either a way to discover the ctxLink on the network, or settings in the user interfaces of the three above mentioned utilities to set the IP address/domain name and port number for ctxLink.
I favour service discovery, so that if you launch a utility it will just find the debug probe and use it. However, that will only work in a LAN, so for truly remote debugging, you will want to set the domain name/IP address and port number anyway.
As an aside supporting ctxLink is on my wish list as well, but I planned looking at it somewhere near the end of February.
@compuphase
My first step in using ctxLink is to connect via USB, in this configuration it presents the same VID:PID as a BMP and with debugging clients this works well. However, BMTrace fails to connect to the ctxLink via USB.
It appears that the ctxLink response to "swdp_scan", which includes a report of the battery state, is confusing BMTrace and the name of the attached MCU is not seen.
I am not sure how to debug this because the code in "bmp_attach" is quite confusing to me. Any suggestion how to further debug this?
@sidprice
After transmitting the "qRcmd,swdp_scan" command (the low-level command for "monitor swdp_scan"), the code goes through the response and looks for any of the following:
- a target output string with the text "voltage:", just to check that the target voltage is not zero.
- a target output string that starts with "1" (after skipping white space)
- a result string with "OK" (GDB does not show result strings in its console).
For the target output strings, there is the additional requirement (in the bmp_attach() function) that the line ends with a newline.
In short: the extra line with the battery should not cause trouble (at least, not until you say something like "Battery voltage: 0V"; then that 0V will be mistaken for the target voltage, right now).
On line 217, there is size = gdbrsp_recv(buffer, sizearray(buffer), 1000);
Look what the output is at each iteration. "buffer" should get the text line by line starting from "Target voltage" op to "1 STM32F40x M3/M4" (each line prefixed with the letter "o"), and end with "OK".
@compuphase After a little more checking BMTrace now connects via USB with ctxLink. However, it is not showing any data. I do see data on the SWO pin. Where is a good place to check what BMTrace is getting, if anything?
@compuphase It appears the issue is mine with ctxLink, I will let you know how this first phase of testing goes.
The utilities have been adapted to also support ctxLink, via USB and Wi-Fi. The guide has coverage of ctxLink as well. It has been tested primarily under Windows. There has been limited testing under Linux.