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?


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.

  • 1
    \$\begingroup\$ I have no idea why they are doing it, but since its in the datasheet, you have to live with it. It appears to be a pretty dumb design. Don't fret over the "why". Looking at the datasheet, it doesn't appear you need to send the dummy bit 0 on writing. \$\endgroup\$
    – tcrosley
    Jul 27, 2015 at 1:48
  • \$\begingroup\$ but it cuts my values, and corrupts them. I am trying to find why to see if there is reason for that. \$\endgroup\$
    – user505160
    Jul 27, 2015 at 1:51
  • 2
    \$\begingroup\$ @user505160 The chip does not corrupt your data by inserting a dummy bit, it's your program that corrupts the data by not ignoring the dummy bit. \$\endgroup\$
    – user253751
    Jul 27, 2015 at 2:36

1 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).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.