QSPI Not waking from deep sleep on startup

RE: QSPI Not waking from deep sleep on startup

ovrebekk — Fri, 18 Mar 2022 11:23:29 GMT

Hi Ed

Yes, we are working on a new way of assigning and configuring pins used by peripherals, and recently all our drivers were updated in upstream Zephyr to support PINCTRL (find a related commit that changed the QSPI driver here). All board definitions are also being updated to use PINCTRL.

These changes will be introduced in NCS 2.0.

Best regards
Torbjørn

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Thu, 17 Mar 2022 18:26:21 GMT

So the premise of 43766 seems to work fine but the file itself seems to be a bit ahead of the current nrf connect releases so I had to adapt it. Next I will look at adapting the idle code. Is there a new release coming up? I noticed a bunch of CONFIG_PINCTRL logic in the driver that is not in current releases.

RE: QSPI Not waking from deep sleep on startup

ovrebekk — Thu, 17 Mar 2022 08:45:33 GMT

You welcome, just let me know if you have more questions or comments.

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Wed, 16 Mar 2022 12:38:39 GMT

Thanks for the update I will look into these pull and get back to you.

RE: QSPI Not waking from deep sleep on startup

ovrebekk — Wed, 16 Mar 2022 07:23:29 GMT

Hi again

Apparently someone already created a PR to add the CONFIG_NORDIC_QSPI_NOR_IDLE_IN_DPD configuration to the QSPI driver (based on the SPI NOR implementation), but the developer was not convinced these changes were applied correctly.

That said, keep in mind that with the nRF Connect SDK you could always make the changes yourself and create a PR to have us include it in a future release.

Best regards
Torbjørn

RE: QSPI Not waking from deep sleep on startup

ovrebekk — Tue, 15 Mar 2022 09:47:06 GMT

Hi Ed

Thanks for the clarification, that makes sense. I will inquire if this is something we can look into.

In the meantime the developer created a PR to fix the sleep issue. He wasn't able to test it himself since he doesn't have the right hardware available, so if you are able to test it that would be appreciated:

https://github.com/zephyrproject-rtos/zephyr/pull/43766

Best regards
Torbjørn

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Mon, 14 Mar 2022 13:07:11 GMT

As I stated earlier SPI Nor a config CONFIG_SPI_NOR_IDLE_IN_DPD which handles all transitions to and from DPD in the read and write functions of the driver which is the most appropriate place for this to be handled. I included the link to the config description and I had previously pointed out their implementation in spi nor.

docs.zephyrproject.org/.../CONFIG_SPI_NOR_IDLE_IN_DPD.html

RE: QSPI Not waking from deep sleep on startup

ovrebekk — Mon, 14 Mar 2022 08:46:25 GMT

Hi Ed

[quote user="edmcnicholas"]I would like to add that this feature is more useful with the idle in deep power down like the nor spi driver.[/quote]

Are you able to elaborate a bit on this?

You mean you would like to see some other changes to the driver as well?

Best regards
Torbjørn

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Fri, 11 Mar 2022 14:20:25 GMT

Thanks for the update. I would like to add that this feature is more useful with the idle in deep power down like the nor spi driver.

RE: QSPI Not waking from deep sleep on startup

ovrebekk — Fri, 11 Mar 2022 09:50:43 GMT

Hi Ed

There is, yes.

I discussed the issue with the developer, and he agreed that this was an issue in the driver.

The short term workaround is to remove the "has-dpd" property for flash devices that our driver doesn't properly support, but he will work to include a fix in the driver that will send the Release from Deep Power Down command (0xAB) during the initialization phase of the driver.

Most likely he will have a pull request ready within a couple of days, which you can test out on your end.

Best regards
Torbjørn

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Thu, 10 Mar 2022 18:08:26 GMT

any updates?

RE: QSPI Not waking from deep sleep on startup

ovrebekk — Mon, 07 Mar 2022 14:23:24 GMT

Hi Ed

Sorry for the slow response, I was on travel all last week.

I have asked the developers for some input on your findings, and will try to get back to you in a day or two.

Best regards
Torbjørn

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Thu, 03 Mar 2022 20:05:28 GMT

so are you going to put in a ticket to fix this in an upcoming release? The current driver is not in line with standard QSPI ics.

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Wed, 02 Mar 2022 18:06:06 GMT

The implimentation for idle in dpd would be found in lines 463 to 497

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Wed, 02 Mar 2022 18:03:50 GMT

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.

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Fri, 25 Feb 2022 15:26:59 GMT

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

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Fri, 25 Feb 2022 15:09:33 GMT

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.

RE: QSPI Not waking from deep sleep on startup

ovrebekk — Fri, 25 Feb 2022 14:44:39 GMT

Hi Ed

Thanks for the additional information.

[quote user="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?[/quote]

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.

[quote user="edmcnicholas"]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.[/quote]

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

Best regards
Torbjørn

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Thu, 24 Feb 2022 22:12:19 GMT

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

RE: QSPI Not waking from deep sleep on startup

ovrebekk — Thu, 24 Feb 2022 08:50:50 GMT

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

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Wed, 23 Feb 2022 14:25:15 GMT

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

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Wed, 23 Feb 2022 14:05:09 GMT

Also how would reset wake the qspi from deep sleep?

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Wed, 23 Feb 2022 14:01:29 GMT

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?

RE: QSPI Not waking from deep sleep on startup

ovrebekk — Wed, 23 Feb 2022 13:56:10 GMT

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

RE: QSPI Not waking from deep sleep on startup

edmcnicholas — Tue, 22 Feb 2022 19:39:32 GMT

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