Author Topic: How to get SPIFlash Library to work on a clone? [ANSWERED]  (Read 7444 times)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
How to get SPIFlash Library to work on a clone? [ANSWERED]
« on: March 12, 2016, 08:35:04 PM »
I'm building a clone so as to more directly measure current used by individual components, and for other experimentation also (checking several permutations on the relative placement of components and comparing the  resulting effect on RSSI noise).  However, I've hit a wall on getting Felix's spiflash library to work with the winbond flash on the clone.  Using the diagnostic sketch from a different spiflash library ( https://github.com/Marzogh/SPIFlash), the windbond chip is confirmed as being the same on both the clone and the Moteino (diagnostic output is exactly the same):
Code: [Select]
------------­Initialising Flash memory..........


----------------------------------------------------------------------------------------------------------------------------------
                                                           Get ID                                                                 
----------------------------------------------------------------------------------------------------------------------------------
                                                       Winbond W25X40BV
----------------------------------------------------------------------------------------------------------------------------------
JEDEC ID: ef3013h
Manufacturer ID: efh
Memory Type: 12h
Capacity: 3013h
Maximum pages: 2048
----------------------------------------------------------------------------------------------------------------------------------
                                                          Write Data                                                             
----------------------------------------------------------------------------------------------------------------------------------
Data written without errors
----------------------------------------------------------------------------------------------------------------------------------
                                                          Data Check                                                             
----------------------------------------------------------------------------------------------------------------------------------
Data Written || Data Read || Result
----------------------------------------------------------------------------------------------------------------------------------
35 || 35 || Pass
-110 || -110 || Pass
4520 || 4520 || Pass
-1250 || -1250 || Pass
876532 || 876532 || Pass
-10959 || -10959 || Pass
3.1415 || 3.1415 || Pass
123 Test !@# || 123 Test !@# || Pass
inputStruct || outputStruct || Pass
0 - 255 || 0 - 255 || Pass
----------------------------------------------------------------------------------------------------------------------------------
                                                     Check Other Functions                                                       
----------------------------------------------------------------------------------------------------------------------------------
Function || Result
----------------------------------------------------------------------------------------------------------------------------------
powerDown || Error code: 0x06
Pass
powerUp || Pass
sectorErase || Pass
chipErase || Pass
----------------------------------------------------------------------------------------------------------------------------------

Also,  the other spiflash library has no problem interacting with the winbond chip, whether it be on the Moteino or on the clone.  On the other hand, Felix's library works on the Moteino, but hangs on the clone during flash initialization.   :o  In case you're wondering, the diagnostics show the same error code 0x06 on both the clone and the moteino (it means CANTENWRITE), and it also gives a "pass" on both.

Anyone have any idea what might be causing Felix's spiflash library to hang on the clone?  Aside from the winbond chip itself, the clone is just a 3.3v 8Mhz Pro Mini.  On both the Moteino and the clone, chip select for the flash memory is D8.
« Last Edit: March 18, 2016, 02:51:15 AM by WhiteHare »

jra

  • Jr. Member
  • **
  • Posts: 81
  • Country: us
Can you wire it up to a 328p on a breadboard and run it at 3v3@16MHz to make sure there are no unanticipated timing dependencies?

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Excellent idea!  So, I followed up on your suggestion and wired up a bareduino that uses a 16mhz crystal and hooked it up to the flash memory.  I tried running the example sketch titled "SPIFlash_ReadWrite" and...the exact same result.  :'(  I also confirmed that the alternative SPIFlash library (the one that can do diagnostics) can still read and write to the flash memory (the same as before) from the bareduino, so no change there either.  Anyhow, it was a worthwhile experiment, because now at least we know it's not purely a 16mhz vs 8mhz difference.  But what else could it be?

I've also tried swapping out the memory chip and using a different one.  No change.   :'(

I notice LowPowerLab's current spiflash library still uses some functions that have been deprecated.  Maybe that has something to do with it?
« Last Edit: March 13, 2016, 04:14:27 PM by WhiteHare »

TomWS

  • Hero Member
  • *****
  • Posts: 1892
Excellent idea!  So, I followed up on your suggestion and wired up a bareduino that uses a 16mhz crystal and hooked it up to the flash memory.  I tried running the example sketch titled "SPIFlash_ReadWrite" and...the exact same result.  :'(  I also confirmed that the alternative SPIFlash library (the one that can do diagnostics) can still read and write to the flash memory (the same as before) from the bareduino, so no change there either.  Anyhow, it was a worthwhile experiment, because now at least we know it's not purely a 16mhz vs 8mhz difference.  But what else could it be?

I've also tried swapping out the memory chip and using a different one.  No change.   :'(

I notice LowPowerLab's current spiflash library still uses some functions that have been deprecated.  Maybe that has something to do with it?
Dumb question: Did you configure D10 as an output?

Tom

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Actually, it was a smart question because no, I wasn't.  So, I guess it defaulted to slave mode rather than master mode, and that explains the hang (though I don't understand why the Moteino didn't also hang....).

So, fixed that, and now there's no more hanging.   :)  Thanks! 

I've moved forward to merely "Init FAIL!"   :(  Well, at least it's progress.   8)

[Edit: For some reason, the lowpowerlab SPIFlash library is reading jedecID as 0, which is what's causing the "Init FAIL!".  The other SPIFlash library reads it correctly, so it's not a hardware problem per se.]
« Last Edit: March 13, 2016, 06:25:59 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
To debug the init fail, I'm now intercepting the SPI transfer calls.  On the exact same hardware (using Arduino IDE 1.6.5), the LowPowerLab's SPIFlash library fails fairly quickly during initialization on its example application:

Code: [Select]
Start...  
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0xAB
  Rx=0x0
  Tx=0x9F
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
Init FAIL!

whereas the alternate SPIFlash library (I wish it had a different name) that can do diagnostics moves ahead without problem on its diagnostics application:

Code: [Select]
Initialising Flash memory..........
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x90
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0xEF
  Tx=0x0
  Rx=0x12


----------------------------------------------------------------------------------------------------------------------------------
                                                           Get ID                                                                 
----------------------------------------------------------------------------------------------------------------------------------
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x9F
  Rx=0x0
  Tx=0x0
  Rx=0xEF
  Tx=0x0
  Rx=0x30
  Tx=0x0
  Rx=0x13
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x90
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0xEF
  Tx=0x0
  Rx=0x12
                                                       Winbond W25X40BV
----------------------------------------------------------------------------------------------------------------------------------
JEDEC ID: ef3013h
Manufacturer ID: efh
Memory Type: 12h
Capacity: 3013h
Maximum pages: 2048
----------------------------------------------------------------------------------------------------------------------------------


The 0x05 transfer command is an SPIFLASH_STATUSREAD.  It both libraries, it returns just 0x00.

The 0xAB transfer made by LowPowerLab's library is a wakeup call to the flash memory, which the other library does not do.  However, merely commenting that out (to minimize the differences) doesn't fix the problem.

The 0x9F command (a request for the JEDEC ID) made by LowPowerLab's library is what forces the failure, as it only returns 0x0000, whereas when the alternate library later issues that same 0x9F command (later down the page), it elicits the correct response (0xEF3013), starting with the very next transfer.

Interestingly, the alternate library's earlier call of 0x90, which is to read the Manufacture/Device ID, actually takes a while and returns 0x000000EF12.  The timing of that latent response roughly coincides with the failure on the LowPowerLab code, which immediately aborts after receiving 0x0000.  Makes me wonder whether the lowpowlab library code would have eventually elicited the desired response if it had tried longer before giving up.

The above is what happens when running on an 8Mhz clock.  I'll now have a look at what happens at 16Mhz.

[Edit1:  So, I re-ran everything on a atmega328p using a 16Mhz crystal and a Duemilanova bootloader (offhand, I'm not sure what the fuse settings are), and the results were exactly the same.]

[Edit2: running the alternate spiflash libary and diagnostic software on a Moteino also produces exactly the same results as it does on either the 8mhz or 16mhz clones]

« Last Edit: March 14, 2016, 09:13:31 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Obviously, the lowpowlab library does work on the Moteino, and for comparison, the results are:

Code: [Select]
Start...  
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0xAB
  Rx=0x0
  Tx=0x9F
  Rx=0x0
  Tx=0x0
  Rx=0xEF
  Tx=0x0
  Rx=0x30
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x6
  Rx=0x0
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x2
  Tx=0x1
  Rx=0x0
  Tx=0x0
  Rx=0x0
Init OK!


The decisive difference is that the 0x9F  command (a request for the JEDEC ID) immediately elicits a  correct response of 0xEF30 instead of 0x0000.

But why the difference?
« Last Edit: March 14, 2016, 09:12:12 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
So, answering my own question that I posed earlier, as to whether or not if the lowpowerlab library had simply been more persistent, maybe it would have elicited a response: no, it wouldn't have.

To find out, I added a bunch more SPI.transfer(0) calls after the original 0x9F command, and it never does respond with anything other than 0x00.   :'(

Code: [Select]
Start...  
  Tx=0x5
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0xAB
  Rx=0x0
  Tx=0x9F
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
  Tx=0x0
  Rx=0x0
Init FAIL!

It's truly weird with a beard.   I guess I'll have to slap on a logic analyzer and/or an o-scope to sort this, or at least add some color as to what might be going wrong.  Since it appears not to be responding, I suspect there may be a frequency mismatch of some kind.  Except why would the alternate SPIFlash library (the one that can do diagnostics) work on all the platforms without any apparent problems? 
« Last Edit: March 14, 2016, 10:13:12 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
I'm now noticing that the maximum input capacitance and output capacitance on this memory chip is 6 and 8 picoFarad respectively.  That seems pretty low.  I'm having trouble even properly measuring its I/O using the logic probe and o-scope that I have, and I'm beginning to wonder if that might be why.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Even on the Moteino, getting good readings on MISO and MOSI is elusive (see attached).  SPI Clock and Chip Select are easily read though.  It does confirm that the SPI Clock is running at 4Mhz, as it should be, and Chip Select is working (obviously), but otherwise it's next to useless...



« Last Edit: March 15, 2016, 12:58:08 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
I added some dedicated male headers close to the flash memory chip for attaching logic probe leads, and now I can capture the full SPI session on the clone.  For the alternate SPIFlash library, it works without a hitch (see attachment).  Its SPI clock is running at 2Mhz.
« Last Edit: March 15, 2016, 05:11:16 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
In contrast, the LowPowerLab SPIFlash library, running its stock example, appears to be stuck in a crazy loop.  It's running on the exact same hardware, with the exact same logic probes, as the diagnostic SPIFlash library above, all of which haven't been touched at all.  Only the library and sketch have changed.  It's running the SPI clock at 4Mhz.  Maybe slowing the SPI clock down to 2Mhz will (I hope) fix the problem (see attachment) that's presently manifesting when the LPL SPIFlash library is in use.

« Last Edit: March 15, 2016, 05:13:34 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Well, unfortunately, slowing the SPI clock down to 2Mhz didn't solve it.  Nor did slowing it to 1Mhz, or 500Khz, or even 100Khz.  No change with any of them.

So, back to square 1. 

Does anyone have any suggestions?

[Edit1: It turns out that the very act of measuring the SPI lines using my logic probe will, if using the LPL SPIFlash library (but not the diagnostic SPIFlash library), cause the loop to happen.  If I disconnect the logic probe from my computer, then the loop doesn't happen (but init still FAILS).  So, once again, what could account for the difference between the LPL Library being logic probed and the other library?  I guess I need some other way (?) to probe it.]

[Edit2: Commenting out the wakeup command call from the initialize method in the LPL SPIFlash library has allowed me to run the logic probe without encountering the loop.  From reading the datasheet, I'm fairly sure it wasn't invoked correctly  right anyway.  Besides, the diagnostic Flash library works just fine without calling it.]
« Last Edit: March 15, 2016, 07:04:31 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Well, according to the logic probe, the root cause of the problem when the LPL SPIFlash library is running is that MOSI does not seem to transmit anything.  Thus, there is no response elicited over MISO.

i.e. it looks as though SPI itself isn't working properly.  Perhaps there is some conflict between the LPL SPIFlash library and the SPI library but which, for some reason, does not manifest on a Moteino?

So, now why that would be--and only with the LPL SPIFlash library and not the alternate diagnostic library--is the next question.  Does anyone here know anything about SPI that might help answer the question?

I'm obviously grasping at straws here, but could fuse settings have anything to do with it?  What other differences could there be?

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6007
  • Country: us
    • LowPowerLab
Just a wild guess ... capacitive coupling maybe distorting the signal to the point where it's garbled? But ... at such low speeds (16mhz) I would not really expect this.
What does this clone look like?