What is limiting the sampling frequency and timestamp accuracy in CubeMonitor acquisition?

[A.D.]

I use the CubeMonitor 1.5 to log and analyze an int32 variable in an STM32L4 controller.

I need to get a new value every 500us, so I use a custom sampling frequency of 2000 Hz.

For some reason the signal is not sampled reliably in 500us intervals. It does work for some period of time. After that the logging skipps one or several samples before continuing with a 500us sample period. Sometimes 10 or more samples are skipped.

I use an ST-Link with an SWD frequency of 4.6 MHz, so I don't see how the SWD bandwidth could be limitting. 4 Byte with 2 kHz sampling frequency requires only 64 kBaud.

Is there anything I can do to get a more reliable and fast readout of STM32 variables?

PS: That the timestamp is only stored in ms resolution is not helpful either, it would be a huge improvement if the timestamp could be stored with higher resolution (at least 100us steps). I use logging to csv in the "myVariables" processing node.

[KnarfB]

Don't think that you will get a definitive answer because the performance depends on your overall system.

https://www.st.com/en/development-tools/stm32cubemonitor.html#documentation talks about "The sampling rate can reach 1000Hz for a single variable..." leaves not much hope to achieve 2000Hz.

There is a snapshot mode whet the firmware fills data in a buffer, this might help, but I haven't used it yet: https://wiki.st.com/stm32mcu/wiki/STM32CubeMonitor:How_to_perform_an_acquisition_in_snapshot_mode

hth

KnarfB

[A.D.]

Don't think that you will get a definitive answer because the performance depends on your overall system. 

Ok, but what does that mean? It would be great to get some clues where the limiting factor might be. The clock of the µC should be unrelated, right? SWD will run independently from any µC clock and even in low power modes. So I don't see what I could change on the controller to increase performance.

The computer is a modern system with a fast CPU, so I can't imagine the bottleneck to be there.

When ST says that 1000 Hz might be achievable with a single variable, then there is some inherent limit? Maybe ST-Link can't run faster?

[stephane.legargeant]

Hello

The limitation is mainly on the computer : the Operating System including the USB protocol is not designed for very fast acquisition of small piece of data. In direct mode, each access is requested by the computer, so it is not very fast. Moreover if the OS is frozen for few milliseconds, the sampling is delayed.

The snapshot option can be helpful because with snapshot the acquisition is performed in the STM32 and then buffered to the computer.

Best regards

Stephane

[A.D.]

I see, that does explain it.

So I guess figuring out how the snapshot mode exactly works will be my best bet, although thats not such a great solution with all the additional overhead target-wise.

[A.D.]

@stephane.legargeant​ 

I have one further question regarding this topic: Is CubeMonitor reading that value via the SWDIO or SWO pin?

And does that differ depending on wether polling mode or snapshot mode is used? Because comments in the snapshot embedded code suggest that the data is sent via the trace port. This would mean, that this functionality is only available when using the SWO pin?

[stephane.legargeant · Accepted solution]

Hello A.D.

The data are read via the SWDIO. The SWO is not used by STM32CubeMonitor.

In snapshot mode, the data acquisition is done on the STM32 by code copying the variables in a buffer. Then the PC use the SWDIO to read the buffer asynchronously.

One SWDIO access can transfer a buffer covering multiple acquisitions, so the throughput can be higher than when the tool poll each variable separately.

Best regards

Stephane

[A.D.]

Great, thank you for the fast response, that really helps a lot.

[Piranha]

Apart from the other factors already explained, look at the release notes - it's built on Node-RED, Electron and Node.js... It's a web page and therefore cannot perform by design!