4

I am looking at a SPI EEPROM chip on board which is unfortunately hidden under an epoxy blob. However, I was able to determine the pinout thanks to the silkscreen.

Dumping the EEPROM with a Bus Pirate, I figured that the EEPROM is 16K since the dumped data seems to repeat every 0x4000 bytes.

I hooked up a logic analyzer to the pins and monitored communication with the EEPROM while the device booted. The sniffed communication looks very much like SPI (as it should), however there is a slight discrepancy from the spec I haven't figured out yet.

I've screenshotted three examples of what seems to be a READ operation:

Screenshot 1 Screenshot 2 Screenshot 3

The first byte is 0x03 (READ), followed by three bytes, and a two-byte response on MISO. According to the SPI protocol, a READ opcode should be immediately followed by a two-byte address. Then, data is returned from that address.

However, three bytes follow the READ opcode, not two. Looking at each example, the first byte always seems to be 0x00. The next two bytes may conceivably be the address.

My questions boil down to:

  • Is this normal behavior for SPI chips?
  • How should this seemingly non-standard communication be interpreted?
  • Are there more effective ways of decoding this captured traffic into human-readable SPI commands?
7

There is no SPI specification that dictates things like read codes or address lengths, AFAIK; these are chip-specific and have been generally standardized by vendors of SPI EEPROMs and flash chips (though I"m not aware of any formal agreement among vendors).

Most SPI EEPROMs use two bytes to specify the read address, because they are so small that they only need two bytes to address all of the memory on the chip. Most SPI flash chips are larger and use three bytes (they also use the same READ and WRITE codes that SPI EEPROMs do).

So what you are seeing appears to be valid; if I had to guess, I'd say that the chip under the epoxy is an SPI flash chip rather than an EEPROM, but from the standpoint of reading the data from the chip there's little difference, besides the length of the address.

This does not explain why your data appears to be repeating every 0x4000 bytes though. One thing you can try is the RDID command (0x9F) that is implemented by most SPI flash chips (though not EEPROMs to my knowledge). This should return a 3-byte value identifying the manufacturer ID, the device ID and the memory density (aka, the size of the chip). Here is a datasheet from a typical SPI flash chip which provides more detail on the typical RDID implementation.

If this is an SPI flash chip, I would expect the RDID command to work, and you'll know for sure what the size of the chip is; if it doesn't work, then I would venture to guess that this is an EEPROM chip whose vendor decided (for whatever reason) to use 3-byte addresses instead of 2.

  • Ah, I didn't realize SPI was so unstandardized. It responded to RDID with 0xc2 0x05 0x16, so it's definitely flash. Now to find a datasheet... – mncoppola Mar 13 '14 at 21:12
  • FWIW the SPI flash standardization is somewhat being forced by Intel who requires a specific set of commands for flashes that may be used in their boards. – Igor Skochinsky Mar 14 '14 at 0:39
  • The first byte, 0xC2, indicates that it's made by Macronix, a very popular flash chip vendor. IIRC, the last byte, 0x16, indicates that it is a 4MB chip (1 << 0x16). – devttys0 Mar 14 '14 at 1:07
  • Yup, you're right. I googled the ID values and located the datasheet for the chip, and it's a Macronix MX23L3254 (macronix.com/Lists/DataSheet/Attachments/1233/…). It's a 4MB chip, which explains the 3-byte addressing. Thanks for the help! – mncoppola Mar 14 '14 at 1:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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