QSPI flash DPD mode

[Tiit]

Hi

I struggle with my external QSPI flash and power consumption of our custom board (at least I think that would be the problem with too high idle power consumption). We use W25Q512 flash and the device works with this overlay:

&qspi {
	 status = "okay";
	 pinctrl-0 = <&qspi_default>;
	 pinctrl-1 = <&qspi_sleep>;
	 pinctrl-names = "default", "sleep";
	 w25q512: w25q512_0@0 {
		compatible = "nordic,qspi-nor";
		reg = <0>;
		sck-frequency = <133000000>;
		jedec-id = [ef 40 20];
		readoc = "read4o";
		writeoc = "pp4o";
		size = <DT_SIZE_M(512)>; //512Mb
		has-dpd;
        t-enter-dpd = <3000>;
        t-exit-dpd = <3000>;

We optimized our code to go sleep after some measurements (it's a battery powered sensor device), but I see still 2..3 mA current draw. I almost scrapped one board searching where the power goes and last thing (ofcourse NRF52840 too) on the board was flash chip -- the current draw with flash chip was 1.9 mA and when I removed the chip, fall the power consumption in idle mode to 30..35 uA.

I tried pm_device_action(flash_dev, PM_DEVICE_ACTION_SUSPEND), errata 122 fix (*(volatile uint32_t *)0x40029010ul = 1ul; *(volatile uint32_t *)0x40029054ul = 1ul;) and  nrfx_qspi_uninit(); but the power consumption did not change at all after them.

Can I do something else with my flash or maybe has someone used the same chip and knows a bit more about that?

SDK, we use, is NRFConnect 2.6.0

Tiit

[Simonr]

Hi Tiit

I discussed a similar issue a few months back with the QSPI driver developers internally.

Some external flash devices are sometimes able to wake up from DPD mode to standby when the CS line is pulled low, but the CS is under control of the peripheral. Most SPI devices are put to sleep and woken up by a SW command so the thing that sends the command (QSPI peripheral), should not be uninitialized in such a case.

So the correct sequence in such a scenario would be to not use the DPD mode, but to power down/shut off the external NOR flash entirely instead of putting it in a DPD mode, then uninitializing the peripheral and putting the nRF5x into system OFF mode. Then you can wake up the nRF5x that will be able to run qspi_init() successfully.

You can also check out this fix for DPD exits with devices that ignore non-DPD commands while sleeping. Although it is for the nRF Connect SDK it should also be useful here.

Best regards,

Simon

[Tiit]

Actually we don't need to put device system off state, SYSTEM ON  idle is I think good enough. I read about the ERRATA 122 and tried to uninitialize QSPI bus -- maybe has newer versions of SDK already fixed that and it's not neccesary anymore.

[Simonr]

Hi

If I recall correctly, errata 122 is covered in the latest nRF Connect SDK versions, so that shouldn't be it. Can you confirm that the nrfx_qspi_uninit() function runs correctly and completes? I see you have configured the clock speed to run at 133 MHz, but the nRF52840 only supports QSPI clock speeds of up to 32MHz I'm afraid, so that could be a factor to the large current draw as well. You could also after the qspi uninit function, make sure the external flash no longer gets power by using a GPIO for power control for example.

Best regards,

Simon