Hi nordic team,
I have tried enabling SQSPI on the system off sample, but the power consumption jumped to 6.3mA in system off mode; I tried to disable the cpulfpr core but couldn't find anything, so I have attached my sample code with system off and sqspi enabled to help identify why the current remains so high.
Regards,
Hi,
In system off mode, the cores are switched off, and the system should be in sleep mode.
If you see excessive current draw at this point, I would recommend that you look into your gpio states, specifically the CSN pin in this case. This should be high in idle state.
Are you testing on a custom board or a nRF54L15-DK?
Kind regards,
Håkon
Could you clarify if you are referring to the CSN (Chip Select) pin? If so, yes, it remains HIGH during System OFF mode.
I am currently building for the nrf54l15 target, and my custom board uses the same flash IC and the same configuration as the DK.
For context, this is a custom board. The baseline consumption is 2.6 µA when the flash is not in use, so the 6.3 mA draw appears specifically linked to the SQSPI being enabled.
Hi,
Q1: Is this replicable on other boards, including a nRF54L15-DK?
Q2: Can you share how you setup the pull for the different GPIOs, ie. an updated version of your system_off sample?
Kind regards,
Håkon
Hi,
The 0.6 mA was beacuse I was powering using J-link once I switched to a different supply, I was getting 80uA (typical for this hardware).
Is this replicable on other boards, including a nRF54L15-DK?
As mentioned earlier I am unable to test currently on dk. However, I replicate this with another PCB and it resulted on same behaviour. Removing flash from circuit reduced power consumption to 80uA on system off mode. So I guess it's ground floating issue with flash.
On code I have noticed that this behaviour started once I added this to my dts.
/ {
chosen {
nordic,pm-ext-flash = &mx25r64;
};
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
softperipheral_ram: memory@2003c000 {
reg = <0x2003c000 0x4000>;
ranges = <0 0x2003c000 0x4000>;
#address-cells = <1>;
#size-cells = <1>;
sqspi: sqspi@3b40 {
compatible = "nordic,nrf-sqspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x3b40 0x200>;
status = "okay";
zephyr,pm-device-runtime-auto;
};
};
};
};
&cpuflpr_vpr {
pinctrl-0 = <&sqspi_default>;
pinctrl-1 = <&sqspi_sleep>;
pinctrl-names = "default", "sleep";
interrupts = <76 NRF_DEFAULT_IRQ_PRIORITY>;
status = "okay";
};
&sqspi {
mx25r64: mx25r6435f@0 {
compatible = "mxicy,mx25r", "jedec,mspi-nor";
status = "okay";
reg = <0>;
jedec-id = [c2 28 17];
quad-enable-requirements = "S1B6";
sfdp-bfp = [
e5 20 f1 ff ff ff ff 03 44 eb 08 6b 08 3b 04 bb
ee ff ff ff ff ff 00 ff ff ff 00 ff 0c 20 0f 52
10 d8 00 ff 23 72 f5 00 82 ed 04 cc 44 83 68 44
30 b0 30 b0 f7 c4 d5 5c 00 be 29 ff f0 d0 ff ff
];
size = <67108864>;
has-dpd;
t-enter-dpd = <10000>;
t-exit-dpd = <35000>;
t-reset-pulse = <10000>;
t-reset-recovery = <35000>;
mspi-max-frequency = <DT_FREQ_M(8)>;
mspi-io-mode = "MSPI_IO_MODE_QUAD_1_4_4";
mspi-data-rate = "MSPI_DATA_RATE_SINGLE";
mspi-hardware-ce-num = <1>;
mspi-cpp-mode = "MSPI_CPP_MODE_0";
mspi-endian = "MSPI_BIG_ENDIAN";
mspi-ce-polarity = "MSPI_CE_ACTIVE_LOW";
};
};
is there a way to revert these settings before the MCU power off?
Q2: Can you share how you setup the pull for the different GPIOs, ie. an updated version of your system_off sample?
I was adding GPIO_PULL_DOWN flag to configuration. but since we found out that flash is causing this issue do you still need this?
Hi,
Great to hear that you found the root cause. You are using the exact same flash as present on the nRF54L15-DK.
Check the state of the SPI pins towards the flash device. If I forced CSN low, then I measured an additional 5.1 mA added current.
Ghazi-Faisal said:is there a way to revert these settings before the MCU power off?
If you use the power management subsys, and the sys_power_off API, it should be automatically handled:
I see that CONFIG_PM_DEVICE_RUNTIME is not selected, however; this seems to have little effect when using the build .hex file that was included in your .zip file.
Could you check that your CSN pin is not floating while in system off mode, ie. is at VDD level?
Kind regards,
Håkon
Could you check that your CSN pin is not floating while in system off mode, ie. is at VDD level?
yes it's at VDD level in system off mode
It is very strange that this causes ~6 mA current consumption.
Can you share the log output from when the current consumption is high?
Just want to know if the the firmware runs as expected, and is not halted/faulting for some reason? Ie. can you generate a wake-up condition using the button, and see that the log outputs correctly etc?
Kind regards,
Håkon
It is very strange that this causes ~6 mA current consumption.
Can you share the log output from when the current consumption is high?
Just want to know if the the firmware runs as expected, and is not halted/faulting for some reason? Ie. can you generate a wake-up condition using the button, and see that the log outputs correctly etc?
Kind regards,
Håkon
I've attached code and logs. Note that system didn't turned off when I monitored logs.
SEGGER J-Link V8.96 - Real time terminal output SEGGER J-Link V9.6, SN=69652068 Process: JLinkExe *** Booting nRF Connect SDK v3.2.1-d8887f6f32df *** *** Using Zephyr OS v4.2.99-ec78104f1569 *** [00:00:38.219,070] <inf> system_off: nrf54l15dk system off demo [00:00:38.219,078] <inf> system_off: Wakeup from System OFF by GPIO. [00:00:38.219,084] <inf> system_off: Retained data not supported [00:00:39.111,332] <inf> system_off: Entering system off; press sw0 to restart
While trying to fix this, could you also let me know whether it’s better practice to switch off ICs using the VDD bus rather than using separate grounds?
Hi,
Any external logic that is physically turned off, but has traces connected to the nRF GPIOs, needs special attention. These GPIO signals must be low or floating (with input buffer disconnected).
I see that your external flash is connected to the switched net "GND1" - all connections towards this flash IC must be low/hi-Z if this device is unpowered.
Kind regards,
Håkon
Any external logic that is physically turned off, but has traces connected to the nRF GPIOs, needs special attention. These GPIO signals must be low or floating (with input buffer disconnected).
Since the CS pin remains high even when the device is physically disconnected, could that indicate that current is being drained through this pin?
I see that your external flash is connected to the switched net "GND1" - all connections towards this flash IC must be low/hi-Z if this device is unpowered.
I did try a hardware workaround by breaking the GND1 trace from the flash and reconnecting the flash ground to the main GND, and that worked fine. However, I’m exploring whether this can be handled through firmware instead, as it would make it much easier to program all PCBs consistently.
Hi,
Ghazi-Faisal said:Since the CS pin remains high even when the device is physically disconnected, could that indicate that current is being drained through this pin?
Yes, /CSN will backpower the IC.
MOSI can potentially also source the unpowered flash IC.
Kind regards,
Håkon