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):
------------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.
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:
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:
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]
Obviously, the lowpowlab library does work on the Moteino, and for comparison, the results are:
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?
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. :'(
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?