STM32CubeMonitor-Power issue/enhancements

[DAlbe.3]

The STLink V3-PWR has the potential to be a great tool.  However, STM32CubeMonitor-Power (v1.2.1) has a critical issue that seems likely to generate many unnecessary support calls to ST: there is no way to run the tool without logging acquisitions to disk...and at high sampling frequency, it captures a LOT of data. I discovered this the hard way when I ran it overnight with the acquisition time set to infinite and the next day my drive was full.  Even worse, it's not obvious where all that data is stored (Users/myUserName/AppData/Local/Temp/Power_Monitor/Acquisition).

Please consider allowing users to run the tool and observe consumption without also logging the data to disk.  A few simple UI controls would add a great deal of value and I suspect most of these are low-effort.  The first one is the difference between this being a daily-use tool and one that is marginally useful.

1. Checkbox to enable/disable logging (should be disabled by default)
2. Link to folder where logs are kept
3. Pause/Run button to allow users to freeze an event while monitoring it
4. Cumulative power usage counter - this is more important than it sounds; it's what lets IoT device developers gain confidence that their device is consuming power at the expected average rate over a long test cycle.
5. Cursors to measure events (OK, this one isn't as simple as the others)
6. Adjust the Y-Axis to mA when showing more than 10000uA.  It is surprisingly harder to distinguish 15000uA from 150000uA than 15mA from 150mA when things are changing quickly.

[Simon V.]

Hello,

Thank you for your inputs. I agree with your remarks and you can refer to UM2202 document which indicates that during long time acquisition if free storage size becomes lower than 100 Mbytes, acquisition automatically stops.

The purpose of the software tool is to record and simply observe or analyze current waveform. If you have more specific requirements, you can refer to um2269 syntax trough com port  communication to interact with the STLINKV3-PWR at your convenience.

Regards,

Simon

[DAlbe.3]

Thank you Simon, I can only tell you that after I ran an overnight high-resolution acquisition, my Win11-64 machine was in trouble the next morning due to lack of disk space; it's possible that there was still 100MB free, but whatever space was free, the machine was struggling due to lack of disk space; at least as importantly, it took quite a while to find where the acquisition files were stored so I could delete them (see suggested enhancement #2).

I understand the purpose of the software tool, but I'm not sure I understood your suggestion with respect to UM2269; were you suggesting that I write a complete replacement for STM32CubePowerMonitor rather than submitting an enhancement request?

Most of the changes I suggested are low-effort, high value and I hope you'll consider adding some of them into the next release of STM32CubePowerMonitor.  Suggestion #1 (the ability to monitor without acquisition to disk) seems particularly easy and is almost a requirement for the tool to be useful at high resolution.

If ST doesn't have the bandwidth to enhance the tool, perhaps ST would consider open-sourcing it instead so the community can enhance it without much cost to ST (maybe just oversight/code review).

[Simon V.]

Hello,

I shared your enhancements request internally. In parallel you can use the following flow example running with STM32CubeMonitor to develop your own graphical user interface.

Regards,

Simon

[nobody]

Hi,

Thanks for the example, it is great as a starting point.

As soon as I open some of the function nodes they have errors.

 

Has nodeRed got some version changes that is not anymore working, or do I have to do somewhere some global settings?

Thanks in advance
nobody

[Andrew Neil]

I got pointed to this old thread by this:

https://community.st.com/t5/stm32cubemonitor-mcus/stm32-cube-monitor-power-having-multiple-bugs/m-p/647731/highlight/true#M1126

 

---

@DAlbe.3 wrote:

Even worse, it's not obvious where all that data is stored

---

I haven't used it for a while, but that was certainly one of my key gripes with it!

And, to make that worse still, even after you've specified a location of your own, it never remembered that - always went back to its inconvenient default.

[Simon V.]

Hello,

This is relative to nodeRed version changes. It looks it is need now to add "var" declaration with new variable to avoid error. It looks there is no parameter in STM32CubeMonitor to avoid this code update.

I will update the example on my side.

 

Regards,

Simon

[Simon V.]

Please find the updated project json file.

Regards,

Simon