ST 93C66 microwire EEPROM sniffing.

[firewalker]

I am trying to sniff the communication between a micro and an ST 93C66 EEPROM (93C66 6 ST K033M) of a vehicle instrument cluster. I am using sigrok (Pulseview), but everything I try there seems to be something strange to the communication.

I desoldered the EEPROM, read with an eeprom reader and sniffed the protocol. Sigrok was able to decode as normal. So my logic analyzer work OK.

Any hints?




I am attaching the sigrok files.

[Pokey]

Hello. I have the same problem, did you solve it?

[firewalker]

No.  I din;t had the time to further investigate the issue.

Alexander.

[Pokey]

I solved this puzzle. In my case they are using hardware SPI in 16-bit mode in the microcontroller. The 93C86 memory expects a READ instruction which is 13 bits long. (SB (start bit)= 1, OPCODE = 10, ADDR = A9-A0). To align to 16 bits, the first 3 bits on MOSI are "0". Quote from datasheets: "If CS is high, but Start condition has not been detected, any number of clock cycles can be received by the device without changing its status (i.e., waiting for Start condition)." So the 93C86 recognizes the command only from the first bit in the "1" state. The protocol decoder in PulseView does not know this condition described in the documentation, therefore it cannot correctly recognize the communication. In attachment: Req. CLK Cycles 29 means 13 cycles per instruction + 16 cycles per data read.

[firewalker]

Nice. Should I open a bug report to the sigrok?

Alexander.

[Pokey]

I think so. This is an oversight in the decoding protocol for this type of memory. The start condition is not only high on CS, but also high on DI on the rising edge of the clock.