STLINK-V3PWR and STM32CubeMonitor-Power bumpy ride, where to file bugs

[hb1]

Since I haven't found a proper way to send bug reports, I do it here. If there is a better way, please tell me so.

Situation: Latest STM32CubeMonitor-Power (1.2.1), a new STLINK-V3PWR (V3PWR V4J2B1P4), all on latest Intel MacOS Ventura. High power USB port (tested several ports, no change).

My device has several power caps (normal), be it on the primary power line and attached to the peripherals that I can power on/off via the CPU to preserve power. I wish to monitor the overall device's power use. So I got the STLINK-V3PWR.

When monitoring power usage via STM32CubeMonitor-Power, I found a rather blocking problem: whenever my device's power consumption spikes (when switching on, or switching on a peripheral, meaning: when power caps get charged - so in all a very short spike), the software shows a message "VOUT turned off due to OverCurrentProtection". And so it does. After that, I find that I cannot simply power on again, I must unplug the programmer AND shutdown/restart STM32CubeMonitor-Power for the latter to see the programmer again. Sometimes, but not always, I don't even have to stop the software, because it crashes by itself after such a message. This happens even when I set the Current threshold to 500mA.

2 issues with this:

1. can the sensitivity to OCP be lowered somewhat? Allow a bit of time before triggering?
2. is it possible to allow the software and the device continue working together after an OCP event?

Easiest way how to reproduce:

• connect STM32CubeMonitor-Power to STLINK-V3PWR
• set Acquisition Time to infinite (this might not be needed for reproduction, it is just what I use)
• set Current threshold to something big
• Sampling Frequency is not important
• start acquisition
• OUT turns on, a graph appears.
• connect an electrolytic 1000uF between GND and OUT (lower capacities also work, this is just the easiest)
• bingo: the above mentioned alert message
• on the programmer, USB led is green, COM, OUT and AUX glow red slightly, just like after a fresh plug in, but the STM32CubeMonitor-Power software refuses to detect the device, even after a restart.
• one has to also unplug and reconnect the programmer to start again.

Now of course you can say: "OCP got triggered correctly, and the measurement should stop". But the software and the device should be robust against such an event. By at least not crashing. And preferably, by also allowing some short time before triggering.

EDIT:

More detailed log of case reproduction:

This is a serial output log from a STLINK-V3PWR , with only a 1000uF cap connected to OUT. Freshly plugged in, no commands sent yet. 

(empty lines removed in the log)

stlp >

(command sent: pwr off) <-- important. If not sent, "start" will power on immediately and the device will NOT crash.

ack pwr off

(discharged the cap)

(command sent: start)

2461-07

2481-07

...

2510-07

2442-07

(command sent: pwr on)

2481-07

2501-07

1833-04

6071-04

6072-04

6072-04

ack pwr on

stlp > 6072-04

6071-04

6072-04

6072-04

6072-04

6072-04

6072-04

1840-04

2146-07

2215-07

error: VOUT turned OFF due to OverCurrentProtection

stlp > 2274-07

2284-07

end

summary beg

Acquisition mode:  CURRENT

Sampling frequency: 10000 Hz

Acquisition time:  6526 ms

Number of samples: 65263 samples

Current min:    214 uA

Current max:    607 mA

summary end

>> and the COM port disconnects, making a physical reconnect mandatory.

This shows that the COM port disconnection is a firmware issue: the processor has full control after the event.

Other way of reproducing:

This is a serial output log from a STLINK-V3PWR , with only a 1000uF cap connected to OUT. Freshly plugged in, no commands sent yet. 

(empty lines removed in the log)

stlp >

(command sent: pwr off)

ack pwr off

(discharged the cap)

stlp > ack pwr on

stlp > 

stlp > ack pwr off

(discharged the cap)

stlp > ack pwr on

stlp > 

error: VOUT turned OFF due to OverCurrentProtection

stlp > 

>> and the COM port disconnects, making a physical reconnect mandatory.

This shows that the OverCurrentProtection is a firmware issue. The first power on, there were no problems. The second power on, the event triggered. And it shouldn't.

Conclusion:

1. Both the unjustified overcurrent protection triggering and the COM port disconnect are firmware issues.
2. As it stands now, this device can only monitor targets that have no power caps.

[MCesn.1]

I'm expiring the same problem. Even worse I get the "VOUT turned off due to OverCurrentProtection" message by much smaller capacitors, it crashes much sooner. If you turn on a circuit with cca ~100uF capacitors you get the error.

Which unfortunately makes the power monitor pretty useless...

[MCesn.1]

I solved my issue by implementing a hardware workaround.

I prepared a circuit with a manual switch and some additional capacitors. To operate without encountering "OverCurrentProtection" errors, I followed these steps:

1. Initially, I powered up the board (with the added capacitors) using only the AUX output. This was necessary to allow the capacitors to charge up.
2. I then connected the OUT pin to the board (together with AUX).
3. Finally, I disconnected the AUX output from the board.

After removing the AUX output, the board can be charged normally using the OUT pin. The additional capacitors prevent the occurrence of "OverCurrentProtection" errors when activating any additional peripheral devices.

[DAlbe.3]

Consider a soft-start circuit

This is also a hardware fix, but one you might consider for your design in general.  Devices with a lot of bulk capacitance create a huge inrush current when powered on and often benefit from a soft-start circuit.  A soft-start circuit can be (and usually is) as simple as a P-FET with low Rds, two resistors, and a capacitor.  The FET source goes to Vcc and the FET drain goes to the circuit you wish to power.  The gate of the FET is tied to Vcc through the capacitor (C1) and a high value (e.g. 1M) resistor (R1) used to discharge C1 when power is removed.  The gate also has a lower-value resistor (e.g. R2=100K) to ground.  When you apply power to Vcc, capacitor C1 gradually charges through R2 and as it does, the gate voltage (Vgs) ramps gradually down so the FET turns on slowly, limiting the inrush current into the circuit being powered.  Choose C1 and R1 to provide the desired ramp time. This is usually good for your power supply, many types of bulk capacitors, and, in this case, for debugging 🙂

[hb1]

With the latest firmware V4.J3.B1.P4 (get that from a fresh install from stsw-link007, the versions included in the other STM32 tools are likely to be obsolete), the sensitivity to power caps is much less. 

Whenever you have a hard overcurrent, the device still disconnects (requiring a physical reconnect)  and STM32CubeMonitor-Power still crashes. But we're getting closer to a usable device now.