Why does SPI flash has HOLD# pin, as opposed to stopping the clock

There is no concept of 'delimiting' bytes in SPI. The simple fact that 8 bits have been transmitted constitutes a byte, and the ninth bit would be the first bit of the next byte.

In SPI reception begins when the chip select line is lowered (or raised for some chips). The data is then clocked in one bit at a time into a shift register. As each bit arrives the shift register shuffles all the bits down one.

An SPI chip typically has a fixed shift register size, and is not bound by byte sizes. Some have multiples of 8 bits, which is nice, some have 10 bits, some 17 bits, etc.

If you clock in more than the required number of bits the first bits kind of drop off the end of the shift register and are lost, so if you have a 10 bit shift register, and you can only send multiples of 8 bits (which is common with the PIC chips), then if you send the first byte as 6 bits of 0 followed by 2 bits of data, then a second byte of 8 bits of data, the first 6 bits will be discarded as they drop off the end, and the shift register will only contain the last 10 bits.

Addressing modes are basically taking a few extra bits in the SPI data stream and comparing them to a set of pins tied either high or low on the chip. If they match then the data in the shift register should be acted upon. If they don't then it should be discarded.

A number of SPI chips include a pass-through function where you can chain them together, and as data is clocked into the first chip what is at the end of its shift register, and would normally be discarded, is sent to an output pin. This can then go to the input of the next chip thus passing the data down the line from chip to chip. In this case it is critical to make sure your data is packed into a single stream with no bits that you'd normally discard (can be tricky if the chips don't use multiples of 8 bits).

The number of 'wires' in SPI is misleading at best, as it doesn't really tell you how many real wires are needed.

Typically you have:

• Clock
• Chip Select
• Data in
• Data out

Some chips may not have a data out, and they only accept data into them. Some combine the in and the out together, so you have to split them apart somehow - either in software if you can, or in hardware.

If you have both data in and data out, then SPI can work in full duplex mode (but doesn't always) where as you clock data into the shift register, data is also being clocked out for you to read. This isn't often used, as most systems rely on a command being sent before a response can occur. There is sometimes another line to signal when the data has finished being sent to the SPI device and the response should be sent. More often, though, it happens when a certain number of bits have been received, or a certain combination of bits. It is common to pad the start of a transmission with 0 then signal the device to start receiving with a start bit.

There are many ways of doing it, and no one ever seems to do the same thing as anyone else - or even as themselves sometimes.

SPI defines how the data is transferred, not how the data is formed.

As far as I can tell, you're doing everything right.

If this were sitting on my workbench, here's the next thing I would do:

On production units, I would make the resistor on MISO a pull-up, rather than a pull-down. Page 37 of the datasheet only guarantees 100 uA on "MISO out high", but over 10 times that current on "MISO out low". The 1.6 mA on "MISO out low" is enough to (dimly) light a high-efficiency LED with an appropriate pull-up resistor to +3.3 V. I find adding LEDs to every questionable signal helps me find problems faster. The 100 uA on "MISO out high" means don't expect the flash chip to work with a pull-down of 33 KOhm or less.

On my test jig (but not on production units), I would temporarily change resistor on MISO changed to weakly pull MISO to around 1.5 V -- that helps distinguish between high (near 3.3 V), low (near 0 V), and tristate (near 1.5 V).

I would re-run the test and make sure the only thing connected to MISO is the o'scope (or logic analyzer) probe and that bias resistor -- not even the PIC connected -- to rule out the possibility that the PIC is somehow accidentally driving MISO to GND.

I would make a custom test program on the PIC that does nothing but select the flash chip, attempt a READ IDENTIFICATION and reads 20 bytes, then deselects the flash chip, and then repeats forever. (It looks like maybe you've already done this).

It's theoretically possible that a PIC chip could be damaged just enough that it gives signals barely strong enough for the logic analyzer to distinguish "0" from "1", but not quite strong enough for the flash chip to distinguish them.

So I might check the voltages by (a) tweaking the custom test program so it runs the CLK at 1 Hz, so I can check each line on the flash chip with a voltmeter, or (b) running the test program at a more typical speed -- 500 KHz or 10 MHz should work fine -- and check each pin with an actual o'scope (not just a logic analyzer).

It's pretty easy to destroy a flash chip so it looks fine under visual inspection, but damaged such that now it won't ever work (always tri-state or always outputs 0).

Perhaps swap the flash chip with an "identical" M25P16 chip on something like the JeeLink and see if the problem follows the flash chip or stays with the PIC chip.

Perhaps re-build the entire circuit with fresh wires, a fresh PIC chip, and a fresh flash chip, and swap the chips around to see if the problem follows the PIC chip, follows the flash chip, or follows the prototype wires.