Can CubeMonitor acquire data in 80 micro-seconds?

RIG · ‎2020-04-29

I tried to get the variable "g_counter1" in 80 micro-seconds for the STM-Studio Example project using CubeMX_ver.5.6.0 and EWARM_ver.8.42.1.

But the result was not as good as the attachment below.

-STM32_CubeMonitor_Result_dashboard_g_counter1.PNG

-Log_myVariables_2020-04-29_14h35m16s.zip

(Log_myVariables_2020-04-29_14h35m16s.stcm)

In the first place, can CubeMonitor be obtained in 80 microseconds?

In addition,

MCU: STM32G0431KB(NUCLEO-G431KB)

This setting information is the following attached file.

-STM32_CubeMonitor_Setup1_Block_diagram.PNG

-STM32_CubeMonitor_Setup2_Variable_AquisitionParameters.PNG

-STM32_CubeMonitor_Setup3_Probe_Protocol_Frequency.PNG

The setting value of this source code is the following attached file.

-STM32_CubeMonitor_SourceCode1_dataAqc.c.PNG

-STM32_CubeMonitor_SourceCode2_dataAqc.h.PNG

Thank you for your guidance.

stephane.legargeant · ‎2020-04-29

Hello

I think it is not possible to monitor continuously the counter every 80 micro seconds.

In snapshot mode, STM32CubeMonitor tool will retrieve the data by buffer : The value are stored in the target in a circular buffer, and STM32CubeMonitor collects the data in buffer as fast as possible. We knows that it takes more than 1ms to read one u32 data, so reading the snapshot buffer will take few ms. (Need to read data and header). So the data buffer is likely to overflow.

This could explain the strange curve you have attached, I see a repeated pattern with :

a small ramp, acquisition is ongoing fine. (May be one buffer of data)
then it becomes constant because there is an overflow, the tools discards data and start to resync
there is a vertical gap because we get in sync the new value

So I don't think that 80 microsecond is reachable. You should try with slower speed, it should give better results.

Best regards

Stephane

View solution in original post

stephane.legargeant · ‎2020-04-29