I have a battery connected to V_in on a load switch that is controlled by D7. Based on the ULTRA_LOW_POWER documentation, I would assume that when the device goes to sleep the output of D7 is either LOW or unpredictable. However, right now the code below is able to keep the board powered up by the battery and wake from sleep mode with no issues. This would mean that D7 remains high even during sleep mode. Should I take caution and choose a different approach even though it works now? Might anyone have an explanation?
- D7 is pulled down by 10k resistor.
- The load switch is active HIGH.
- If the RESET button is hit in this state the device will not boot from battery. I assume this means D7 indeed defaults LOW as expected.
- Device OS 3.0.0
system_tick_t loopTimer = 0;
// This output is staying HIGH even in ULP sleep mode
loopTimer = millis() + 5000UL;
if (millis() - loopTimer > 5000UL)
loopTimer = millis();
SoC = fuelGauge.getSoC();
// If State of charge drops below 50%, go into sleep mode for 30000us
if (SoC < 50)
// ULP Sleep mode should not allow the D7 output to stay HIGH
Thank you for reading.
I’d like to bump this thread as I still have no idea why this is working.
I am able to reproduce this on the eval board, so I know it is not my PCB. Going into ULP sleep mode while writing HIGH to a digital pin keeps the pin output at 3.3V, contrary to the documentation saying all GPIO outputs are turned off.
I believe I am seeing the same thing - I am however using an E-Series board, comparing ULTRA_LOW_POWER vs. HIBERNATE, according to documentation they should be near the same power consumption. However, measuring the current draw using a Nordic Semi PowerProfiler, I can see that HIBERNATE works as specified in documentation, reaching about 120 µA - when I switch to ULTRA_LOW_POWER I am seeing upwards of 40 mA current - switching pins affect the current draw, even though GPIO outputs should be turned off
Thank you for looking into this. Just to clarify, you are using the Nordic Power Profiler (kit) to provide power to the E-Series board, and measuring the output from the Nordic board?
This is interesting. Since the E-Series is doing the same thing, that means the STM32 and nRF52 MCUs are probably not the culprits. I will still look into their docs and communities to see if anyone else has run into this problem.
Very useful info. Thank you!
I am powering the unit solely using the Nordic Profiler kit using their NRF Connect software to log the usage with a sampling speed of 10hz. I am switching to the B523 and B524 to test it a bit further when time allows it.
All the best
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.