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

[edmcnicholas]

Yes as it is reaching the power down state which is the same as spi nor implementation.  I think your qspi  nor relying on cs waking the device is not a standard feature of all qspi flash so it needs to be updated.  my board reaches 55uA total with a gpiote high accuracy event enabled to i would have to say that yes the device is in deep sleep. 

In reading the data sheet it states that the device is designed to only respond to the wake from deep sleep command in deep sleep which i believe is 0xAB.  That is used when waking the device but with only 2 data sheets to look at I would say for safety state the device should sent the wake command at init.  As the device will not respond to the status call so this would preclude Winbond parts from being used.  I am including the section from the data sheet below.

8.2.24 Power-down (B9h)
Although the standby current during normal operation is relatively low, standby current can be further
reduced with the Power-down instruction. The lower power consumption makes the Power-down
instruction especially useful for battery powered applications (See ICC1 and ICC2 in AC Characteristics).
The instruction is initiated by driving the /CS pin low and shifting the instruction code “B9h” as shown in
Figure 37a & 37b.

The /CS pin must be driven high after the eighth bit has been latched. If this is not done the Power-down
instruction will not be executed. After /CS is driven high, the power-down state will entered within the time
duration of tDP (See AC Characteristics). While in the power-down state only the Release Power-down /
Device ID (ABh) instruction, which restores the device to normal operation, will be recognized. All other
instructions are ignored. This includes the Read Status Register instruction, which is always available
during normal operation. Ignoring all but one instruction makes the Power Down state a useful condition
for securing maximum write protection.

[edmcnicholas]

To my knowledge all other devices need the AB command to return from DPD so it seems like maxtronix is the outlier.

new maxtronix chipset

8.22 ENTER DEEP POWER DOWN (DP, B9h) The Deep Power-down (DP) instruction is for setting the device on the minimizing the power consumption (enter into Power-down mode). During this mode, standby current is reduced from Isb1 to Isb2. While in the Power-down mode, the device is not active and all Write/Program/Erase instructions are ignored. The instruction is initiated by driving the CE# pin low and shifting the instruction code into the device. The CE# pin must be driven high after the instruction has been latched, or Power-down mode will not engage. Once CE# pin driven high, the Power-down mode will be entered within the time duration of tDP. While in the Power-down mode only the Release from Powerdown/RDID instruction, which restores the device to normal operation, will be recognized. All other instructions are ignored, including the Read Status Register instruction which is always available during normal operation. Ignoring all but one instruction makes the Power Down state a useful condition for securing maximum write protection. It is available in both SPI and QPI mode

I found the same in cypress memory

4.3.5 Interface Standby When CS# is high the SPI interface is in standby state. Inputs other than RESET# are ignored. The interface waits for the beginning of a new command. The next interface state is Instruction Cycle when CS# goes low to begin a new command. While in interface standby state the memory device draws standby current (ISB) if no embedded algorithm is in progress. If an embedded algorithm is in progress, the related current is drawn until the end of the algorithm when the entire device returns to standby current draw. A Deep Power Down (DPD) mode is supported by the FS-S Family devices. If the device has been placed in DPD mode by the DPD (B9h) command, the interface standby current is (IDPD). The DPD command is accepted only while the device is not performing an embedded algorithm as indicated by the Status Register-1 volatile Write In Progress (WIP) bit being cleared to zero (SR1V[0] = 0). While in DPD mode the device ignores all commands except the Release from DPD (RES ABh) command, that will return the device to the Interface Standby state after a delay of tRES.

Giga memory

7.21. Deep Power-Down (DP) (B9H)
Executing the Deep Power-Down (DP) command is the only way to put the device in the lowest consumption mode (the
Deep Power-Down Mode). It can also be used as an extra software protection mechanism, while the device is not in active
use, since in this mode, the device ignores all Write, Program and Erase commands.
Driving CS# high deselects the device, and puts the device in the Standby Mode (if there is no internal cycle currently in
progress). But this mode is not the Deep Power-Down Mode. The Deep Power-Down Mode can only be entered by
executing the Deep Power-Down (DP) command. Once the device has entered the Deep Power-Down Mode, all commands
are ignored except the Release from Deep Power-Down and Read Device ID (RDI) command or software reset command.
The Release from Deep Power-Down and Read Device ID (RDI) command releases the device from Deep power-Down
mode , also allows the Device ID of the device to be output on SO.
The Deep Power-Down Mode automatically stops at Power-Down, and the device is in the Standby Mode after Power-Up.
The Deep Power-Down command sequence: CS# goes low → sending Deep Power-Down command → CS# goes high.
The command sequence is shown below. CS# must be driven high after the eighth bit of the command code has been
latched in; otherwise the Deep Power-Down (DP) command is not executed. As soon as CS# is driven high, it requires a
delay of tDP before the supply current is reduced to ICC2 and the Deep Power-Down Mode is entered. Any Deep Power-
Down (DP) command, while an Erase, Program or Write cycle is in progress, is rejected without having any effects on the
cycle that is in progress.

ISSI

8.22 ENTER DEEP POWER DOWN (DP, B9h) The Deep Power-down (DP) instruction is for setting the device on the minimizing the power consumption (enter into Power-down mode). During this mode, standby current is reduced from Isb1 to Isb2. While in the Power-down mode, the device is not active and all Write/Program/Erase instructions are ignored. The instruction is initiated by driving the CE# pin low and shifting the instruction code into the device. The CE# pin must be driven high after the instruction has been latched, or Power-down mode will not engage. Once CE# pin driven high, the Power-down mode will be entered within the time duration of tDP. While in the Power-down mode only the Release from Powerdown/RDID instruction, which restores the device to normal operation, will be recognized. All other instructions are ignored, including the Read Status Register instruction which is always available during normal operation. Ignoring all but one instruction makes the Power Down state a useful condition for securing maximum write protection. It is available in both SPI and QPI mode

[edmcnicholas]

After searching code please refer to  1.9.0\zephyr\drivers\flash\spi_nor.c for the proper implementation.  In their code they issue a return from DPD on init. 

This is how the qspi should be implemented.  Ideally there would also be an idle in standby like the spi nor code as well. 

function "static int spi_nor_configure(const struct device *dev)" line 1031.