How to get SPIFlash Library to work on a clone? [ANSWERED]

[WhiteHare]

Photo attached.

[Felix]

Is this a $2 arduino mini?
Any doubt that's a genuine atmega chip or is a reject?

[WhiteHare]

Is this a $2 arduino mini?

yes

Any doubt that's a genuine atmega chip or is a reject?

I don't know.  The hardware does work without a hitch though (see reply #10 above) using the diagnostic spiflash library.  I've also tried it with different (DIP) chip and hardware (a virtualbotix bareduino 16mhz atmega328p purchased through amazon), and it's the same results.  So, given the same results using two very different pieces of hardware...

[emjay]

@Whitehare,

If you want to dig deeper, I suggest you 'deadbug' wire the little flash daughter board direct to the pins on the clone and don't have the SPI bus signals connecting to the breadboard at all.  There is considerable capacitance loading on the signals with the current setup.

Adding scope and/or logic probe just makes the loading worse.  You can check the waveform rise/fall times if you put a tiny C value in series with the probe e.g. 1.5pf with a typical 15pf probe tip will divide the signal by ~10 (compensate with extra gain) but only be a small additional load on the bus signal.   You are looking for runts, slow risetimes, ringing etc.

If you don't have a small value SMD handy, just use a cm of tightly twisted pair, the self-capacity will do the trick.

[emjay]

@WhiteHare,

I doubt it - their input capacitance is too high.  At least while you are debugging, you need to get the bus loading capacitance down.

[WhiteHare]

Thanks!  That's what I didn't know.  I'll skip the optocouplers then.

[WhiteHare]

OK, I threw together a deadbug (see attached), and... same results.  Argh!  As before, the alternate SPIFlash library works, but the LPL SPIFlash library results in "Init FAIL!".  I even deleted the LPL SPIFlash library and downloaded a fresh new one from LPL github repository.  Same results.

In case you're wondering, the Winbond flash chips came from Digikey, so presumably no problem there.  For the deadbug I used a different Winbond flash chip, just in case the previous two might have been dodgy.  Obviously, that made no difference.

If it *is* a capacitance issue, then maybe the flash chip's breakout board is the source?  I'm not sure I have the skill to deadbug without it, but I suppose I could try.  But if that's the case, why on three different hardware testbeds now does the diagnostic SPIFlash library work and the LPL SPIFlash library fail?  I don't get it: if it were a hardware problem wouldn't the diagnostic SPIFlash library fail too?

[emjay]

Neat. Now what do the bus signals look like on the scope (LPL v. non-LPL library)?

[Felix]

You showed a logic trace earlier where issuing 0x9F (read ID) from the other library, gets the right ID back, but issuing the same command with my library fails.
That's good, but confusing to me, why the same code would work on a Moteino... but not on a 'clone'. So definitely some issue somewhere, i'm on the fence between an electrical issue or firmware/library. I was going to suggest fuses, but that can't be it. SPI Initialization maybe? Clocks really don't matter that much, 4mhz is not a problem, never saw an issue, BUT with a clone where capacitive coupling might be an issue you could divide by 8 or 16 instead of just 4.

EDIT: Can you try my SPIFlash library at this point in history, when it did not include the SPI_TRANSACTION support?
How about trying the latest version with IDE 1.0.6 where SPI_TRANSACTION was not available?

[TomWS]

You showed a logic trace earlier where issuing 0x9F (read ID) from the other library, gets the right ID back, but issuing the same command with my library fails.

Actually, if you look at the posted sequence, the SPIFlash Library issues a 9F command (Read JEDEC ID) while the other sequence was issuing a 90 command (Read Manufacturer ID).

EDIT: Can you try my SPIFlash library at this point in history, when it did not include the SPI_TRANSACTION support?
How about trying the latest version with IDE 1.0.6 where SPI_TRANSACTION was not available?

Another thing to check, using the current library, is that SPI_HAS_TRANSACTION is defined.  Maybe this was lost (or whimsically changed) in this version of the IDE.

Tom

[Felix]

You showed a logic trace earlier where issuing 0x9F (read ID) from the other library, gets the right ID back, but issuing the same command with my library fails.

Actually, if you look at the posted sequence, the SPIFlash Library issues a 9F command (Read JEDEC ID) while the other sequence was issuing a 90 command (Read Manufacturer ID).

Tom, I was referring to this post where @WhiteHare mentions that with the alternate library, reading the id works. The trace shows a 9F command followed by the expected 0xEF30 reply. At least that's what I see.

[WhiteHare]

EDIT: Can you try my SPIFlash library at this point in history, when it did not include the SPI_TRANSACTION support?

No improvement when running it on 1.6.5. 

EDIT:
How about trying the latest version with IDE 1.0.6 where SPI_TRANSACTION was not available?

Success!  Running the library above that you linked to on IDE 1.0.6 produces "Start...Init OK!"     I didn't even have to add

Code Select Expand

pinMode(10,OUTPUT);

to the example sketch that came with the library.  I also didn't have to comment out the wakeup() function call in the flash initialize method.  In both cases, just running the code as given does not appear to result in any hangs or fails.

[UPDATE: the current SPIFlash library also appears to work under Arduino IDE 1.0.6.  i.e. 1.0.6 is the key!

I wonder why it doesn't it work on the later IDE releases, like 1.6.5?]

[WhiteHare]

Another thing to check, using the current library, is that SPI_HAS_TRANSACTION is defined. 

I have  confirmed that, yes, it is defined.

[emjay]

@WhiteHare,

Well done - persistence pays off.  Now digging out the actual reason will probably need a look at the generated code in combination with monitoring the SPI traffic. Presumably you can just focus on the offending transaction(s) in a loop - if you're not tempted to score the victory and just move on... 

[Felix]

Success!  Running the library above that you linked to on IDE 1.0.6 produces "Start...Init OK!"     I didn't even have to add

Code Select Expand

pinMode(10,OUTPUT);

to the example sketch that came with the library.  I also didn't have to comment out the wakeup() function call in the flash initialize method.  In both cases, just running the code as given does not appear to result in any hangs or fails.

[UPDATE: the current SPIFlash library also appears to work under Arduino IDE 1.0.6.  i.e. 1.0.6 is the key!

I wonder why it doesn't it work on the later IDE releases, like 1.6.5?]

Great work.
It's pretty amazing, how does it feel to discover firmware (the latest greatest IDE 1.6.5) is the problem and that just wasted a few days of your life, and an unknown number of hairs and neurons? Relief and grief huh?

I never liked any of the IDEs above 1.0.6. That one doesn't have the fancy library management, but it just works. I'm not 100% sure what to say about SPI_TRANSACTIONS, they seem to be a good thing, seem to work and are meant to keep newbies from having to know what's going on under the SPI hood. You confirmed the latest SPIFlash (includes SPI_TRANSACTION support) also works in 1.0.6, which of course is what I use and I can also confirm that.

Anyway, maybe something can be done in the SPIFlash lib to make it work in 1.6.5, maybe some little patch or something. If you find the magic bullet let me know