LowPowerLab Forum

Hardware support => Moteino => Topic started by: snorp on April 26, 2016, 10:33:44 AM

Title: SPIFlash::initialize() hanging
Post by: snorp on April 26, 2016, 10:33:44 AM
I've been playing with my first batch of Moteinos that are flash-enabled, and frequently when resetting the device after programming via FTDI, SPIFlash::initialize() will hang. It seems to be the wakeup() call that causes this. Does anyone know why this happens? I do sleep() the flash during the normal startup sequence, so I guess that may be part of the problem. I found one thread suggesting a 10k pulldown on MISO, but that seemed to make the radio act funny (wouldn't receive packets in listen mode).
Title: Re: SPIFlash::initialize() hanging
Post by: WhiteHare on April 26, 2016, 12:19:48 PM
It's a known problem.  Here's the exact answer:  https://lowpowerlab.com/forum/index.php/topic,1714.msg12473.html#msg12473
Title: Re: SPIFlash::initialize() hanging
Post by: snorp on April 26, 2016, 01:22:22 PM
Hmm. It looks like you still need the pulldown on D12 regardless of the Arduino version? Seems kinda unlikely to be a compiler issue, no? I wish someone with a logic analyzer would figure it out. Really annoying, and like I said, the pulldown seems to screw up the radio somehow for me.

EDIT: undefining SPI_HAS_TRANSACTION in SPIFlash.h does not seem to help things, so I think that may have been a red herring in the other thread.
Title: Re: SPIFlash::initialize() hanging
Post by: WhiteHare on April 26, 2016, 01:43:36 PM
You really should re-read the link I gave you more carefully.  I'm skeptical a megaohm pulldown resistor is going to screw up your radio.
Title: Re: SPIFlash::initialize() hanging
Post by: snorp on April 26, 2016, 01:50:13 PM
The reason wakeup() hangs is because it's stuck waiting on busy() to return false. The status register continuously returns 0xff, which just seems to be bogus. If I just treat 0xff as non-busy, the rest of the initialization goes fine. The write-enable latch status is correctly set, etc. Removing the wakeup() call in initialize() would also work, but it seems like it would be necessary, right? If we do a reset without a power cycle, the flash should be sleeping so why does this work?
Title: Re: SPIFlash::initialize() hanging
Post by: WhiteHare on April 26, 2016, 02:04:41 PM
Well, at least you're asking the right questions....  I hope you find (and post) a better solution.  I wish I had all the answers, but I don't.  Everything I know or found out is already documented in that other thread.  I think the problem is probably both compiler and hardware related, because reverting to the earlier IDE by itself doesn't completely fix things.
Title: Re: SPIFlash::initialize() hanging
Post by: snorp on April 26, 2016, 02:10:32 PM
Quote from: WhiteHare on April 26, 2016, 01:43:36 PM
You really should re-read the link I gave you more carefully.

Hmm, which part? You were pretty clear with:

Quote
[Edit: I do, however, still need the megaohm pulldown resistor on D12 if I am to wake-up the flash memory after explicitly putting the flash memory to sleep.  Without the pulldown, even if the R4 firmware is built using IDE 1.0.6, the result is still in a hang when trying to wake the flash memory.   :(  The unit I tested is an R4 running direct from two AA batteries and with the stock LDO voltage regulator removed.]

I don't see how the IDE version is in play if they behave the same and you still need the pulldown...

Quote
I'm skeptical a megaohm pulldown resistor is going to screw up your radio.

I was using a 10k resistor, but I'll try a megaohm one.
Title: Re: SPIFlash::initialize() hanging
Post by: WhiteHare on April 26, 2016, 02:38:16 PM
You might try experimenting with bypass capacitors.  My current hypothesis is that the megaohm resistor provides an alternate path to ground for noise, and, if so, a cap would probably be a better conduit.  That connecting DTR to ground worked at all is, I think, evidence in support of that theory.  Some perhaps weaker evidence is the presence of RSSI noise that's measurable when a Moteino is inside a sealed metal can and with its antenna shorted to ground.  Alternately, if you have the right fancy equipment, which I can only wish that I did, you might be able to measure it directly.