Which debug hardware / IDE is best suited to run variable tracing in real-time and with high update rate (130kHz), without interfering with the software?

[MTeus.1]

I use the STLINK-V3MINI in combination with STM32CubeIDE and STM32G4x µC. With SWV a tracing of 2 variables with 20kHz is possible without data loss.

What are the limitations of the STLINK-V3MINI, and what justifies the purchase of an expensive debugger? - Is logging in this frequency range possible with an expensive device?

I refer to the following article which gives a good overview, but I get lost in the amount of possibilities.

https://www.st.com/content/ccc/resource/sales_and_marketing/presentation/product_presentation/group0/51/b5/28/37/25/93/48/83/stm32-stm8_software_development_tools.pdf/files/stm32-stm8_software_development_tools.pdf/jcr:content/translations/en.stm32-stm8_software_development_tools.pdf

Does anyone have experience with this topic?

[waclawek.jan]

> variable tracing... without interfering with the software

There is no such thing. The on-chip debugger *is* intrusive... everything which reads data changes the minute details of system timing.

And there is no one-perfect debugger. At the end of the day, the real debugger sits on your chair. It's how you can use the toolbox what counts, not one individual tool.

If you desire high-frequency updates, one option might be to dump the variable(s) onto SPI using DMA, captured by a general-purpose LA.

JW

[MTeus.1]

@Community member thank you very much for your quick reply.

What I understood is that the use of SWV Data Trace does not affect the programflow itself.

But, since the same areas of memory are accessed by different hardware, the timing is not changed any more or less than when a DMA reads data. Ideally, these two should not affect each other.

How exactly this timing works in the Cortex M4 of the STM32G474 I haven't found yet.

I want to avoid putting a lot of additional software in my program to get accurate debug results. Especially if there is a possibility to get accurate results without it.

"And there is no one-perfect debugger. At the end of the day, the real debugger sits on your chair. It's how you can use the toolbox what counts, not one individual tool."

I completely agree, but when the limits of the existing tool are reached, it makes sense to look for something better.

[waclawek.jan]

> What I understood is that the use of SWV Data Trace does not affect the programflow itself.

Sorry, I misunderstood the method - I though you intend to periodically read out the variables, as e.g. CubeMonitor does.

Usign DWT->Trace is indeed non-intrusive. It's then up to you (system clock, pin(s) drive/load, capabilities of the debug "pod" used, willingness to use a big enough package and giving up pins of it for the synchronous/parallel trace) how fast data can be shoveled out, it can go up to pretty high rates with the synchronous output (I am not sure about the details, not interested, but surely mega-events per second).

It's questionable whether this is worth at all. DWT can capture only changes in data which originate in the processor itself, i.e. cannot monitor hardware-initiated changes in hardware registers, nor data changed by other busmasters e.g. DMA.

JW

[Piranha]

Take a look at SEGGER's RTT:

https://www.segger.com/products/debug-probes/j-link/technology/about-real-time-transfer/

[Singh.Harjit]

If you want the CPU to not be involved, then you have to use SWJ-DP with AHP-AP. Where something external has to resolve the variable location and run cycles to pull in the information. You will need a mechanism to sync up your reads through this mechanism with whatever the CPU is doing.

Segger's RTT is a really good option but it requires the CPU to write data into areas and then you pull them out. An open source alternative is: https://cortexprog.com/. This too requires the CPU to do the copying and then using the SWJ-DP/AHP-AP mechanism, you can pull out the data.

A really good solution I've heard of for this was - the team put local SRAM/DRAM and streamed the data to it.

With the QUADSPI and PSRAM, it should be super doable to accomplish this but you won't be able to monitor in real time...

[MTeus.1]

Segger J-Link (Debug / Trace) seems to be the right choice here. However, I have not yet found whether one of these debuggers also supports these additional data lines "TRACEDATA [3:0]" of the TPIU.

These can be configured in the CubeMX and I assume it is these additional 4 tracepins for a data communication.

 

https://cortexprog.com/ looks interesting, will this be developed further?

[Singh.Harjit]

Not sure what is left to develop. When I last looked at it, it looked pretty complete.

[uJogi.1]

You must use SWJ-DP with AHP-AP if you do not want the CPU to be involved. The information has to be pulled in by something external that resolves location and runs cycles. Your reads will need to be synchronized with whatever the CPU is doing with this mechanism.

 RTT provided by Seeger is great, but you need to write data into areas and then pull them out. You can also use https://apkfl.com/ as an alternative. To do this, you use the CPU to copy and then use the SWJ-DP/AHP-AP mechanism to retrieve the information.

[S.Ma]

When trying to watch memory values at high rate, becomes closer to monitor the internal memory bus every cycle... so cheap solution would be DAC or PWM output updated by timered DMA, external xSPI RAM bus monitoring, FMC lc 6809 mode like....

[S.Ma]

The spi mode going to external DAC or LED strip is probably scalable too