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]