BMTrace not displaying data

[sidprice]

I have a very simple program running on an STM32F415RG:

` int _write(int file, char ptr, int len) { int i = 0 ; for ( i = 0 ; i < len ; i++) { ITM_SendChar(ptr++) ; } return len ; }

int main() { /** *

• Place your code here. **/ int cnt; Setup() ; porta.MakeOutput(LED_PIN, OSPEED_LOW); cnt = 0; do { char loopMsg[32] = {0} ; printf("Loop is %d\n",cnt) ; // trace(0, &loopMsg[0]) ; cnt++; porta.Set(LED_PIN); DelayTenth(10); porta.Clear(LED_PIN); DelayTenth(10); } while (1); `

I have BMTrace set for "Manchester, CPU clock = 100000000, Bit Rate = 200000. It does not show any data from the target. The only display is "Connected [STM32F40x]

I am trying to create a test setup so that I can work on SWO data from my ctxLink Wireless Debug Probe, a wireless version of BMP.

[sidprice]

@compuphase I think I know what the issue is. The MCU reported by the BMP is "STM32F40x" and there is no entry matching this in the device scripts so BMTrace is only running the "generic-swo" and not running anything for the target MCU.

Not sure of the best way to resolve this, other than if a reported MCU name starts with "STM32F" then it should be truncated to only have one more character. So, "STM32F40x" would be truncated to "STM32F4" and the script selector would run the correct script.

What do you think of this idea?

[sidprice]

@compuphase I made a PR #12 however, I still do not see any data from my target.

Any other suggestions?

[compuphase]

I still have to look at you pull-request. I took the strings for the targets from the BMP source code version 1.6.1; they probably changed (and new ones were probably added). This can occur more often in the future. I have on my to do list to split off these configuration scripts into user-editable configuration files, so that new targets can be more easily added.

I assume you are testing on your ctxLink. The bitrate of 200 kbps is too high for the BMP. Note that for Manchester, there are two edges per bit, so BMTrace sets the clock (TPIU_ACPR register) for twice the given data rate (so 400 kHz in your case). I read in other messges here on Github that 100 kHz is roughly the maximum for reliable tracing with Manchester on the BMP and I think they mean clock, not bitrate. So on a real BMP, you must probably go down to 50 kbps.

First thing to check is whether you see data on the SWOTRACE pin of your target. Second thing to check is whether ctxLink is decoding it and sending it to the USB port. Third test is whether BMTrace receives any data at all (function trace_read() in file swotrace.c).

As an aside: wasn't ctxLink going to do Asynchronous SWO (NRZ) instead of Manchester?

[sidprice]

@compuphase , thanks for the response.

I am currently using a native BMP so that I can get a test setup working before I move on the using ctxLink. Initially, because I will be using my pre-production ctxLink, it will also be Manchester output.

I will change the bit-rate to 50KHz and see what happens, however, I am not seeing data on the SWO pin as I would expect.

Splitting off the "scripts" into separate files is an excellent idea and will avoid having to rebuild the tool to add a new MCU :)

[sidprice]

@compuphase I changed the bit-rate to 50000 but do not see any data in BMTrace.

I have my 'scope on the SWO pin and I see a burst of activity on SWO right after I start BMTrace, however, nothing is displayed and also there is no further data on the SWO pin.

[compuphase]

@sidprice OK, another experiment: add the initialzation code for SWO tracing to your firmware. Then you should see activity on the SWO line at each iteration of the loop (even "monitor traceswo" is not given to the BMP). If you have a logic analyzer on the pin, you would be able to decode the packets.

I implemented the script for the STM32F4 family from the manual and an example I found somewhere (plus the register definitions I took from a header file). I never tested it, because I don't have a board with that MCU. So one possibility is that that script has a bug.

[sidprice]

@compuphase I have the trace being initialized by my firmware and I am now getting data on the SWO pin. However, when I start BMTrace I get an assertion:

`Assertion failed!

Program: C:\DataRoot\Projects\Black-Magic-Probe-Book\source\bmtrace.exe File: swotrace.c, Line 1173

Expression: idx == 0 || pos >= timeline[chan].marks[idx - 1].pos ` I am using a message string output once-per-second:

sprintf(&loopMsg[0],"Loop is %d\n",cnt) ; char *msg = &loopMsg[0] ; while(*msg != 0 ) { ITM_SendChar(*msg++) ; }

[compuphase]

@sidprice I don't understand why the assertion fires. It is as if the static variable timeline was not zero-initialized...

Try to check the value of idx at that point. It should start at zero and it should increment (although it may not increment at every iteration, but it should never decrement or skip a value).

If you want to go ahead with your testing, you may put a "return -1" near the top of the function timeline_widget() starting at line 1190 in swotrace.c. Then the timeline is just blank (but the assertion won't ever get hit).

As an aside, you now got SWO output. Was there a bug in my code (and guide)?

[sidprice]

@compuphase I think you code in the book for F4 was correct, I had a small issue with my code. I will check my trace init code against the book later, but I think it was OK.

I removed the "/r" from my string and now I don't get an assertion, however the display is not good. Attached is screen capture.

I am hacking a capture buffer into BMTrace, to double check what is being received, I think the issue may be in "tracestring_add" when it merges small segments of the strings.

[sidprice]

I don't understand what I am seeing in the buffer I added, I see my strings but there is also other data mixed in with it. I guess I just don't understand what is going on.

[compuphase]

@sidprice I will look into the issue with tracestring_add(). For every character that you receive over SWO, you will also see a header byte. This will have the channel number in the top 5 bits and a byte count in the low 3 bits. In your case, you should see a byte with the value 1 in front of every character (channel 0, 1 character payload).

[compuphase]

@sidprice I created a bug in a recent update; I have the same issue, so this is a bug in my code, not yours.

[compuphase]

@sidprice Please try commit 959372a78b81dcf8f7922d1f05c586d2e160f7e8. Sorry for the trouble it has given you.

[sidprice]

@compuphase Thank you.

When I use ITM_SendChar to output my messages BMTrace shows the data correctly :)

When I use the 4-character trace function published in your book I do not see any display in BMTrace.

[sidprice]

Also note that the MCU setup for trace by BMTrace also works. I removed the MCU code that initialized trace and let BMTrace do it.

[compuphase]

@sidprice I checked the 4-character trace function from the guide. It works in my case. Note though that you need to set the "Data size" option to 32-bit (or "auto") in BMTrace.

I did spot a minor bug with 32-bit payloads: a dummy (empty) trace string may appear after a valid trace string (due to zero padding on multi-byte packets). This, I will fix.

[sidprice]

@compuphase Great, I switched to "auto" for the "Data size" option and it works.