Does anyone know how to use this feature
I have googled around and it may be that some specific code has to be inserted into the project, i.e. this is not a special type of breakpoint which allows you to printf some variables to some window in Cube IDE. But I am not at all sure... everything I found online seems a mess.
I have set up this dynamic printf and I see a load on debugger activity in the Console window, but no data comes out anywhere obvious.
More basically, I am looking for a way to set up a breakpoint so that it doesn't stop the program but increments a counter. Obviously, the program will be interrupted for some time (does anyone know how long?).
I have noticed there is an ignore count on a breakpoint and perhaps there is some way to monitor that, if it decrements. That must also pause the program, for however long the debugging system takes to process it. Do different debuggers affect this pause? I am using ST-LINK V2 ISOL.
I have also noticed ST-LINK V3 has a VCP (on an extra connector) so if one of the UARTs is wired to these pins, you could run Teraterm on the PC to receive any debugs sent to that UART. But that requires target code, obviously, and my target has a USB port already with a VCP on it so we can send printfs to that.
OK; I had the impression this feature implemented a printf type debug output, to some window in the Cube IDE environment.
I am now looking for a way to set up a breakpoint so that it doesn't stop the program but increments a counter. Obviously, the program will be interrupted for some time (does anyone know how long?).
That seems to be some sort of command line mode. I am using Cube IDE.
However, this
https://sourceware.org/gdb/current/onlinedocs/gdb/Dynamic-Printf.html#Dynamic-Printfsuggests that the dynamic printf does indeed do what I thought it did. And yes the output does end up in the "debugger console" window. So that's solved!
This is a really brilliant feature!
However, I have seen a comment that the execution time is quite long. I may do a setup where two pulses are generated, before and after, and measure it with a scope. Is this feature implemented wholly in the debugger, or does the data travel all the way to the PC via USB, and the printf is implemented on that? I think it must be, since the debugger is a small ARM and an FPGA, and it doesn't appear to be running on the target.
Is this feature implemented wholly in the debugger, or does the data travel all the way to the PC via USB, and the printf is implemented on that? I think it must be, since the debugger is a small ARM and an FPGA, and it doesn't appear to be running on the target.
If by debugger you mean the ST-LINK V3, I would assume the latter. You'd be paying a lot more for something like the former.
Note the "dprintf-style" parameter. I don't know what you already tried, but my reading is that this setting would determine if the printf (or whatever) is executed locally ("call") on the µC or handled on the PC. The former should be faster, but I'd expect both options to be relatively slow (milliseconds, at least) because either way GDB is coordinating things remotely from the PC which is just inherently slow, as you have noted.
I have found yet another way to send debugs: the SWO one-wire debug interface. This is one of the Jtag pins. The debugs come out in the SWV ITM data console in Cube IDE. This is supposed to be fairly fast, since it runs at 2mbps. You have to do something in main.c to connect printf() to this one-wire interface, and it does work.
It is under Run / Debug Configurations / Debugger
I will have a go at timing this to see how much time it steals from the target.
I can see the output (the window in Cube IDE) is not very fast; I reckon it could not display data at a few kbytes/sec. It also usually drops the first byte of the first message. But so long as it runs fast at the target end, that's ok.
Some updates on debug timing. I did a printf("1234567890") and timed the gap with a scope between two pulses generated before and after.
SWO debug / SWV ITM data console: 6-20us
Dynamic Printf / debugger console: 120ms
A slight difference
