• State Not Answered
  • Replies 26 replies
  • Subscribers 74 subscribers
  • Views 5334 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 284592
Options

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);

Parents Reply Children
  • 0 in reply to edmcnicholas

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

  • 0 in reply to edmcnicholas

    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

  • 0 in reply to ovrebekk

    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

  • 0 in reply to edmcnicholas

    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

  • 0 in reply to ovrebekk

    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.

Related
Terms of service