Low Supply Voltage Behavior

What happens when the module’s supply voltage drops below the minimum? Does it shut down? Or does it behave unpredictably? Is there a reference that explains?

Paul

Hi Paul,

The module functions according the PSoC6 Power Supply Protection System. According Cypress:

PSoC 6 device family provides the functional safety to protect a system crash, like the LVD(low voltage detection), the BOD(brown-out Detection), the watchdog, etc. The LVD block can protect the system from a serious power loss as one of the safety function.

The key features are:

  • Monitoring the main power supply voltage(VDDD)

The LVD monitors VDDD and it simply generates an interrupt.

  • Interrupt generation

The LVD generates an interrupt to cause the system to take preventive measures/do some housekeeping before energy runs out.

  • User programmable trip voltage

The trip point of LVD is programmable.

  • Automatic disabling in the deep sleep and hibernate mode

The LVD is disabled when entering the ultra-low power modes to prevent false interrupts during wakeup.

  • No force system reset

The LVD does not reset system, unlike the function of the BOD circuits, but firmware may initiate a system reset if desired.

  • Interrupt edge selection

The LVD can monitor not only falling edge but also rising edge. The rising edge can utilize to check the VDDD settling when system boots up.

I just did a test and the MCU stops when Vdd < 1.7V. When power goes > 1.8V it starts like a reset.

Hope this answers your question.

Rolf

Thanks, Rolf. Can I assume that a similar thing happens with the LoRa transceiver? And if so, would supply current be almost zero?

The reason I ask is because I am trying to implement a LoRaWan node that harvests its power from a small current transformer. As long as the primary current is significant, there is no problem. However, there will be times in which the primary current drops below some value at which point the CT secondary can no longer provide enough power for the module (i.e. a “brownout” condition). Dealing with this condition (especially if it occurs frequently) will be the real challenge.

Assuming that the module doesn’t go into some crazy high current “latch” condition at brownout, my device should be able to restart, once the primary current exceeds the threshold.

I have ordered a developer’s kit and await its arrival. Once it arrives, I can verify brownout behavior.

Thanks for answering my question.

Paul

Hi Paul,

The LoRa transceiver is being reset using the reset-input at startup of the microcontroller. I assume the SX1262 is pretty insensitive for power glitches resulting in a latch-up, as there isn’t a lot of logic inside relatively.

Datasheets usually don’t provide a lot of information on latch-up conditions. PSoC6 has a comprehensive fail-safe system so I’n not too worried on that either.

That said, I think it’s good to contact Cypress and Semtech to ask advice on this matter, as well as extensively test in real-life as well.

Regards,
Rolf

Thanks for the info.

Hi Paul,
One thing that may be good to know is that when the supply voltage goes lower, the current drawn (during transmission) goes up since the RF-chip has an internal dcdc-converterfor the transceiver so that it can have same transmission power for different supply voltages.
BR
/Tomas

1 Like

Tomas,
That’s a good point. I’ll keep it in mind.

In order to operate my node at really low sensed current, I will need to charge a good sized capacitor while the node is asleep. In order for this scheme to work, I need to avoid any situation that prevents enough charge from building up while the node is asleep (i.e. “undefined behavior”).

I’m probably worrying too much, but that’s what I do. I’ll do some testing, once the development board arrives. Thanks for the info.

Paul

Fortunately you can do setup a lot of different configurations. It’s possible to switch off the DC-DC converters for the transceiver as well as for the microcontroller (LDO mode). As a result the current draw will stay the same for different voltages. However the power consumption will increase for higher voltages (as there’s an additional LDO power consumption due to the Vldo * I).

In DC-DC mode the power consumption will not change significantly by applying a higher voltage.

Hi Paul,
Sorry for not answerring earlier. Didn’t see your message. I understand your issue. I am also the type that often sees troubles that may arise early. Sometimes its a good capability and sometimes its better without seeing issues that havent arised yet… :slight_smile:
BR
Tomas

We found out that at certain power-drops while the LoRa radio is in TX or RX mode, the SX126x can cause to remain in the TX or RX state. This results in the M0+ waiting for the IRQ line of the SX126x to go high. When using ‘waitTillFinished = true’, the stack won’t return from the LoRaWAN_Send() call.

This will be fixed in the 0xB6 version of the stack.

Rolf,
This is an example of why I would like to have a reset function that interrupts all the activity in the M0+ as I am waiting on the M0±core to get finished. If it never finishes its work I have a timeout and then would like to be able to force the M0±core to hard reset if this occurs. As I see it the avaialable reset-funtion also waits for the M0±core to get finished?
BR
Tomas

Tomas,

The M0+ Core shouldn’t halt, except as the clocking to the M0+ Core is halted. This could be the issue if if clocking is set to the BLE ECO and next Sleep is called. Sleep disabled the BLE ECO and this will lock the M0+.

The AT command set example on Github shows an example on how to set back clock to the IMO before executing the Sleep functionality.