QSPI Not waking from deep sleep on startup

[edmcnicholas]

In SDK 1.9.0 i saw that QSPI deep power down was implemented and i can confirm that that works using the below code.  The issue I see is that if the device is in deep power down mode and then the device is rebooted and power is maintained in my case through the debugger the device does not reinitialize so this kind of defeats the use of power management.   I also see that the call to get device binding returns a 0 so I can not make a call to run a resume action.

Previous to this I was using the device as SPI NOR and it restarted just fine.  I see that when powered down my board is running at the same power level with both drivers idle.  Is this the wrong code or am I missing something?  I see that dpd is only implemented in the nrf_qspi_nor.c qspi_nor_pm_action function.

Thanks

Ed

#if (CONFIG_NORDIC_QSPI_NOR - 0) || DT_NODE_HAS_STATUS(DT_INST(0, nordic_qspi_nor), okay)
g_qspi_dev = device_get_binding(DT_LABEL(DT_INST(0, nordic_qspi_nor)));
#endif

pm_device_action_run(g_qspi_dev,PM_DEVICE_ACTION_SUSPEND);

[ovrebekk]

Hi Ed

Are you able to provide a bit more information about how the device is rebooted? 

You mean to say it is just waking up from power down, or it is going through a full reset?

Best regards
Torbjørn

[edmcnicholas]

I found this while running on the debugger. When the device is reset I would assume all devices where drivers are provided would be initialized.  It works the first time after power is applied but if reprogrammed I get a null device pointer.

This worked fine configured as spi nor but as qspi nor the device is not reinitializing at startup.  If I don't totally remove power the qspi does not initialize if it has been powered down and return a null device pointer.

I could see this being an issue with mcu boot as well as debugging or reset from watchdog etc

[ovrebekk]

Hi Ed

What if you run a reset manually after programming? Will it work then?

It is quite common to see issues after programming the device if a reset is not explicitly performed. 

Waking from system OFF sleep or a watchdog timer counts as a reset, and should not exhibit this issue. 

Best regards
Torbjørn

[edmcnicholas]

I do that using the debugger unless the reset call in the ide does not actually reset the processor. Shouldn't all of the unit code be run from reset?

[edmcnicholas]

Also how would reset wake the qspi from deep sleep?

[edmcnicholas]

To be mode specific i think this has to do with the qspi nor chip being in deep sleep not the peripheral. 

[ovrebekk]

Hi Ed

Thanks for the clarification, so if I understand you correctly the problem happens when the flash device is in deep sleep when the Nordic device is reset?

This makes sense if the driver assumes that the flash device is active during initialization. Possibly the driver should check this, and try to wake up the device if it is not responding. 

I think I will have to reproduce the issue on my end in order to investigate this further. Do you think one of the standard samples can be used to reproduce it?

Best regards
Torbjørn

[edmcnicholas]

So in looking at the data sheet the qspi flash you use on the dev kit is able to return from deep power down by holding CS low for 20ns but the qpsi we were able to get in the current market W25Q128JVPIQ does not have this feature other chips need the explicit wake command to return to powered on state.  I see now why this might not show up on the dev kit.  Is there a way to work around this?

This makes my wonder how this is working in the spi nor implementation since I don't see this behavior.  That might be a good place to look for what is missing.

Thanks

Ed

[ovrebekk]

Hi Ed

Thanks for the additional information. 

edmcnicholas said:

So in looking at the data sheet the qspi flash you use on the dev kit is able to return from deep power down by holding CS low for 20ns but the qpsi we were able to get in the current market W25Q128JVPIQ does not have this feature other chips need the explicit wake command to return to powered on state.  I see now why this might not show up on the dev kit.  Is there a way to work around this?

Most likely you would need a different driver for you flash device then, using the wakeup command rather than relying on pulling the CS signal low. 

edmcnicholas said:

This makes my wonder how this is working in the spi nor implementation since I don't see this behavior.  That might be a good place to look for what is missing.

Are you sure this driver is using power down at all? 

Best regards
Torbjørn