EEPROM 93C66 dummy bit problem?

Question

Could someone please explain the reason why the 93C66 EEPROM outputs a dummy 0 during a read operation?

From datasheet:

5.1 Read Data from Memory The Read Data from Memory (READ) instruction outputs data on Serial Data Output (Q). When the instruction is received, the op-code and address are decoded, and the data from the memory is transferred to an output shift register. A dummy 0 bit is output first, followed by the 8-bit byte or 16-bit word, with the most significant bit first. Output data changes are triggered by the rising edge of Serial Clock (C). The M93Cx6 automatically increments the internal address register and clocks out the next byte (or word) as long as the Chip Select Input (S) is held High. In this case, the dummy 0 bit is not output between bytes (or words) and a continuous stream of data can be read.

If the input/output is byte oriented, and first bit of a read is a dummy bit 0, all data after that is then shifted (delayed) by one bit to make space for this dummy bit.

For example if the data stored in the EEPROM is:

byte1:[000000001] byte2:[000000001] 

it is read from the EEPROM as:

byte1:[000000000] byte2:[100000000] byte3:[100000000]

I would like to store some data to EEPROM but this shift is the issue, what is the use of this devil thing called dummy 0?

EDIT:

I just want to leave comment on my solution. Because I was able to change IC in my case I went on using 25LC640A-I/P DIL, it behaves like I wanted, so if anyone needs hint here it is.

Answer 1

We use the 9346 on several of our products, and it has this same dummy "0" devil thing.

I think the reason it does this is that it needs to have the last address bit (A0) clocked in before it reads the data and begins to clock out the requested data. If you look at the datasheet, You can see that the Dummy bit overlaps the A0 address bit.

You can fix this by fighting fire with fire :-). Add your own dummy devil bit to the end of the address word (Make the Length one longer), so that your SPI port ignores that first bit of the response, and begins clocking the response at the correct boundary.

Also, I always need to look closely to see that my CPOL and CPHA settings are correct. Sometimes things almost work when these settings are wrong, but are off by one bit (wrong CPHA), or sometimes just unreliable (wrong CPOL).