BMTrace not working on Windows 10

[sidprice]

I have built the master-HEAD and BMTrace does not work with BMP or ctxLink (USB). BMScan correctly detects the BMP attached via USB but when BMTrace is started it displays "Initializing ..." and nothing more.

When I ran BMTrace under GDB debug it was able to connect to the BMP, however, when I selected the configure the target I saw "attach failed" and BMTrace became non-responsive.

Debugging BMTrace is quite complex since I don't know the code well so if you can help to debug this with some suggested items to check I am happy to work on it.

[compuphase]

When BMTrace stays stuck at "Initializing...", it means that it cannot open the virtual serial port (or the TCP/IP port). When it says "Attach failed", it means that any of the commands like "monitor tpwr enable", "monitor swdp_scan" or "attach" failed.

I have been continuously testing with the target powered from ctxLink. Maybe BMTrace has an error in detecting that the target is self-powered, and then enables tpwr (when it shouldn't). I do not have a battery installed; does ctxLink change its response to "monitor swdp_scan" when there is a battery?

[sidprice]

This failure is with both BMP native and ctxLink. When ctxLink failed I changed to BMP to see that work first. I understand what the two messages mean, just having trouble understanding where to begin debug, especially since I tried stepping through the code with BMP and it connected to it. This looks like some kind of timing issue.

[compuphase]

I will test on different PCs; hopefully I can reproduce the problem. This latest version, I have so far only tested on the same laptop that I develop on.

What you can do is set a breakpoint on function bmp_callback() in bmtrace.c, line 120. When the attach fails, the message paramater to bmp_callback() will give a more precise reason for the failure. (Unfortunately, this "more precise" message gets overwritten later by a generic message; I will be looking into that.)

[compuphase]

I commited 7e5bc81 with a few changes, based on testing on a different PC. The notable changes is that I added a few retries (with a delay between the retries) in the final phase of connection. This is based on a case that I stumbled upon where BMTrace would indeed not connect, because it got an unexpected answer to a query.

At the same time I noticed that terminating the thread that captures the traces causes a crash in Linux. This was also fixed, but not relevant in your case (since you are running Windows).

I will continue testing. I am also considering building with MingW for testing. Are you using MingW-w64?

[sidprice]

Yes, I am using mingw-w64 (i686-8.1.0-posix-dwarf-rt_v6-rev0)

[sidprice]

I pulled your updates and built, however I have the same problem of BMTrace showing "Initializing..." and not responding.

[sidprice]

It appears the trace enable is failing. I have a breakpoint in bmp-support.c @ line 687 and the recv count is zero.

[compuphase]

The good news is, it has nothing to do with MingW. The bad news is, I still cannot reproduce the error.

In commit 85d4c00 I added retries for the "traceswo enable" command in bmp-support.c. But it leaves me wondering whether it really is a timing issue (there is a 1 second timeout on receive from the BMP, so the timing issue must then be that the BMP is too late picking the command up, but... there is a hardware FIFO). In case you haven't already done so, can you also check the USB cable and try a different PC?

[sidprice]

I have several BMPs and ctxLinks and they all work very well with GDB. I do not think this is a PC/cable issue.

Unfortunately I do not know how to trap the error. I tried adding a small (100mS) delay before sending the trace command, It did not change anything.

[compuphase]

BMDebug uses GDB in the background. To get SWO tracing in BMDebug, you would have to type in a command like
BMP: trace 12mhz 100khz
ctxLink: trace async 12mhz 100khz
(both assume that the target runs at a clock of 12MHz, and the serial bit-rate is 100kHz).

BMTrace does not use GDB, but instead uses the protocol that GDB also uses to talk to the gdbserver inside the BMP and ctxLink.

So I suggest that you test BMDebug. If that works, it indicates that GDB does something differently than BMTrace. Of course, I copied the protocol used in BMTrace from a dump of a GDB run, but maybe GDB does retries on all commands (which BMTrace does not).

[sidprice]

Some of BMDebug works, it connects to the target and does the swdp scan and attaches. However, it is not loading the code, GDB says to executable has been specified. The filename show in the attached screen capture is NOT the executable file I selected.

I cannot type anything into the command line, it says "Please wait..."

[compuphase]

It is not entirely clear to me what happened in that screen capture, but in trying a few scenarios, I found a few bugs, and fixed them in commit 47a76f6. In any case, I had a bug in handling filenames with a space character in the path.