Hi Diego,
Behavior you are describing looks very strange to me and especially regarding the workaround (removing R155 and connecting R154 with 10k ) that solves your issue.
In the STM32L562E-DK, there are both:
- hardware overcurrent protection (PM_IBREAKER) that controls the output power switch (T6). This signal is filtered by a low pass 1uF/150R to skip overcurrent glitch. This circuitry behaves as hIccup protection...
- software overcurrent protection (PM_IBREAKED) that goes to microcontroller IO to generate interrupt in case of overcurrent (without filter)
Your workaround (removing R155) disables the software overcurrent detection; but does not disable the hardware overcurrent protection.
I suspect there is a very short overcurrent in your application when you enable the Tx (LoRa).
Could you please make a new measurement with STM32CubeMonitor-Power:
- set the sampling frequency to max
- Start acquisition (to infinite)
- enable your application
- Starts Tx (LoRa)
- Stop acquisition then zoom in where Tx started to find peak current (alternatively, you can use "Show Report" on top right to enable frame that shows "Max" current measured during the acquisition)
Please provide Max current and make a screen shot of the curve when this max current occured (and past the screenshot to this post)
By the way, if the current exceed 166mA, it is normal that STM32L562E-DK detects an overcurrent.
