Moteino sleeping the spi flash chip question

[Tomega3]

I have a USB Moteino with the Winbond 4Mbit W25X40CL chip and a RFM69HW radio
I am using the LowPower lib to sleep the radio, the moteino and the flash chip.

Without sleeping (and then waking up the flash chip) everything works fine but after issuing a flash.sleep, the flash.wakeup appears to hang up the moteino. a disconnect and reconnect to a serial monitor (aka reboot) does not clear the hangup, I have to remove the usb cable and reconnect it to get the moteino to startup again. after this restart it will hang again after waking up from the lowpower 8 second sleep command.

Here is the code in my sleep routine

Code Select Expand

#ifdef SLEEP_EN
void enterSleep(void)
{
  Serial.println(F("Time to go to sleep"));
  SLEEPING = true;

  #if defined RADIO_EN
    radio.sleep(); // sleep the radio
  #endif

  #ifdef USE_SPIFLASH
    flash.sleep();  // this seems to lock up the box
  #endif

  Serial.flush();   // empty the serial buffer

  #ifdef USE_LOWPOWER_LIB
    LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);
    // The program will continue from here after the WDT timeout
    delay(1000);                    // give system time to fully power up
    Serial.println(F("Awake from sleep"));
  #endif

  
  // radio will auto wake up upon next receiveDone call

  #ifdef USE_SPIFLASH
    flash.wakeup();    // maybe this is locking up the box
  #endif
  SLEEPING = false;
}
#endif

Question, is this the correct or preferred way to sleep the radio, the moteino and the spi flash chip.
Does the flash.wakeup function in the spiflash lib need to call the command function with an additional parameter?

I am attaching my test sketch, everything works well when I comment out the calls to flash.sleep and flash.wakeup.

Thanks

[Felix]

The problem lies with the open drain MISO input. That's because the chip will only respond to a wake command. Before that is issued, the SPIFlash library will issue a status command and wait for a response which is normally expected to be 0x0 even if the chip is asleep, that is perfectly fine and normal. A non 0 status means there is noise on MISO. That can be induced from static. I recommend using a 10k-100K pulldown on MISO to avoid such hanging problems if you sleep the flash. Although in suspended mode (non sleep) the chip uses only ~10uA, power down (sleep) will be 1uA, see page 39 of DS.

[Tomega3]

Thanks for the info on adding a pulldown resistor on the MISO line, I will give it a try.
Any idea if this will have an impact on the spi radio or other attached spi devices? say a TI CC3000 (wifi) or SD card
My guess is that it depends on each device.

[Felix]

It should not, the pulldown is only there to stabilize against noise. A strong logic 1 on MISO coming from any SPI device will definitely pull MISO high.

[WhiteHare]

The problem lies with the open drain MISO input. That's because the chip will only respond to a wake command. Before that is issued, the SPIFlash library will issue a status command and wait for a response which is normally expected to be 0x0 even if the chip is asleep, that is perfectly fine and normal. A non 0 status means there is noise on MISO. That can be induced from static. I recommend using a 10k-100K pulldown on MISO to avoid such hanging problems if you sleep the flash. Although in suspended mode (non sleep) the chip uses only ~10uA, power down (sleep) will be 1uA, see page 39 of DS.

I'm using a 100k pulldown on MISO (which is D12 on the Moteino).  It seems to keep the flash memory from hanging, but now sometimes the radio hangs, whereas before it didn't.

[Felix]

MISO is a High-Z input so you should not have to add any pull resistors. The SPI slaves are those who pull this line.
Instead the CS lines of the slaves should sometimes be pulled up.

[WhiteHare]

How many ohms do you recommend for the pullup on D8?  Switching to that configuration and using using a 10K resistor, the flash memory is back to hanging when trying to wake it up after sleeping it.

[Felix]

Typical pullups are >10K, 100K sometimes. It has to be weak enough to let a driver pull the line to HIGH or LOW into a HI-Z input.
When hanging happens, trying random things like adding pullups is not exactly the scientific way of doing things, because basically you don't know why something you try makes everything work. We are in the mythical guess land of electronics. It might not work under other conditions, then you are back at trying other things.
A better way of finding the reason is using a logic analyzer, or scope when the issue is more electrical oriented than digital. That finding-the-root-cause-of-issues is part of the electronics 101 steep learning curve, steep but rewarding.

In any case I am interested in finding out if there are real issues with the SPI flash chip I use on Moteinos. I have had other hanging reports but none that I could replicate myself.

[WhiteHare]

I couldn't make the pull-up work, so I went back to the pulldown, since it at least fixed the flash memory problem, even though it annoyed the radio.  Using a 400K pulldown resistor seems to work for both of them, though, as you say, it was purely trial-and-error.  I'd rather that there be solid theoretical underpinnings, but at least for now it works.

[Felix]

Often times in engineering, a band-aid good enough answer NOW is better than a great solution LATER. It's all a matter of weighing the risks.