STM32CubeMonitor 1.4.0 CPU critical performance issue

[acv_atr]

Hello everyone.

I'm trying to work with STM32CubeMonitor to implement an industrial machine Life Test JIG using 12 ST-LINK v2 probes connected to STM32 microcontrollers by SWD protocol, but I'm facing very strange and anoying issues.

This post will focus only on CPU critical allocation on V1.4.0.

When acq node is started (only after receive start acquisition order) the process allocate 100% of one CPU core.

As shown on the picture below, I'm using at the moment and for development purposes, only two ST-LINK probes, that's why "only" two cores are at 100% allocation.

 

This does not occurs on STM32CubeMonitor V1.3.0

 

According to V1.4.0 release notes the multiple probe acquisitions was improved.

 

Windows 10 pro has the same behaviour on V1.3.0 and V1.4.0

Ubuntu 20.04 Desktop has also been tested and verified.

All installation recomendations defined at wiki have been meet.

Question: Is this CPU allocation expected/known and it's a true improvment relative to v1.3.0?

[acv_atr]

Hello everyone.

Has anyone else had this issue?

What is ST position relative to this issue?

Where is the right place to report ST Microelectornics software issues?

Thanks for your attention.

Best regards

[Richard.Chvr]

Hello @_acv_atr​ 

Up to 1.3.0 version, the acquisition was done in only one thread, in multi probes setup there was no more allocated resources.

From 1.4.0 version, each probe have his own thread and it allows to improve the acquisition frequency in multi-probes configuration.

As we have now a dedicated resource by probe we can now reach a specific acquisition frequency . On the other hand the CPUs get more loaded.

Note that acquisition is ordered by the acquisition node, not by the ST-Link.

[acv_atr]

Hello @Richard.Chvr​ 

Thank you for your answer and attention.

I fully understand that you can improve the acquisition frequency allocating 100% of the thread running core. That is obvious.

Considering a quad core computer, that means we can work up to 3 probes simultaneously before lose all resources and have no User Interface answer.

This does not occurs at ST Cube Monitor v1.3.0.

"Note that acquisition is ordered by the acquisition node, not by the ST-Link."

This is true, but this is not related to resource allocation.

You can test it and verify it, but in my application, the sample rate is set to 1Hz and each probe allocates 100% of the core.

[Richard.Chvr]

Hello @_acv_atr​ 

I have no wonder about you 100% cores allocation, no doubt about it

What I meant by "Note that acquisition is ordered by the acquisition node, not by the ST-Link."

is that if ST-Link was acquisition sequencer, you're use case may work.

STM32Cubemonitor is designed to perform monitoring on development phase to get some measures and tune the configuration,

May be we should consider it use for production phase.

[acv_atr]

Hi @Richard.Chvr​ 

I'm sorry to insist, but I cannot figure out any advantage of allocate 100% of a core to get better time/sampling/cycle.... This looks like a "while(1) {....}" condition introduced at v1.4.0 nodes, that only counts time to get the next sample according to your description.

Both of us are using STM32CubeMonitor at development and test phase.

Just consider that we are trying to test/monitor 12 developed produts at the same time, at a life time operation scenarios test ( like IKEA lab test a new chair).

Considering v1.4.0 CubeMonitor version is recommended use 3x quad core computers, or 2x octa cores computers?

Thank you for your clarifications

[acv_atr]

Hi @Richard.Chvr​ 

At the moment I have on top of desk a setup wtih 4x ST-LINK V2 getting data at 1Hz each.

With the same flow and HW you can figure out each screenshoot is from V1.3.0 and v1.4.0 cubeMonitor

I'm using a I5 quad core with 8GB RAM and SSD disk

 

 

[Richard.Chvr]

Hello @_acv_atr​ 

Thank you for your figures, we clearly need a trade of between acquisition frequency optimization and CPU workload which is not acceptable at all at such frequency. Sorry for this issue. Can you use the 1.3.0 version while the dev team works on a new release to solve this issue.

Regards

[ACava.1]

@Richard.Chvr​ 

Any news or update about this subject?

Thanks for your support.

[ACava.1]

Hello @Richard.Chvr​ 

Thre is no news or updates regarding this issue?

Thank you for your attention.