08lj12: SPI operate EEPROM (93c56)

[eexpress]

the EEPROM chip is 93c56. when operate EEPROM thr SPI, all 93c56-PC(DIP, 2MHz clk) is ok. but 93c56-SI27(SOT, 1MHz clk), all write is ok(this verified by other device), but when read, those result data is shift right one bit, just read out 7 bits of most significant byte.

since 93c56 is raising CLK shift in, and falling CLK shift out, and the SPI is all raising SPSCK shift in/out current bit. it seems some critical state when MISO data shift in. or the status just like SPSCK lost the last half edge(one falling edge) at end.

those SPI Baud Rate Select Bits already set to 1/128 of fbus. Power supply is enough.

so, any advice?

[eexpress]

thanks for reply,

assembly code sample is not necessary, since i do this well when using a hc05 chip that also used assembly code.

below is part of my code. i thought it's correct, for i had shift my command part right by one bit before send the command, that already made access 9 bit address.
#define Read1 0b00000011
#define Read2 0b00000000
#define Read 0b00001100 ---this is defined for EE93c56, and is default condition.
void EERead(byte ee_add, char *ram_add, byte len)
{
while(len--){
SS=1;// SPSCR; SPDR; // Clear flag
#ifdef EE93C46
Eesend(Read1); Eesend((byte)(ee_add&Mask|Read2));
#else
Eesend(Read); Eesend(ee_add); --for 93c56, 9 bit address
#endif
*ram_add=Eesend(0); ram_add++; ee_add++;
SS=0;}
}

and why the chip 93C56-PC works well. just different package, so strange.

thanks,

[bigmac]

Hello eexpress,

Sorry - I misunderstood your initial question.  So one part works OK with your code, and the other part doesn't.

Something to check out - I believe there was some variability between manufacturers with the 93C series.  The types I have previously used had an ORG pin to select between 8-bit or 16-bit organisation.  However, I have seen data sheets where this pin was not functional, and where some devices were always 8-bit, and others always 16-bit.  Of course, if your new device is in the latter category, this would be problematic. A check of the data sheet should reveal if the ORG pin is available for the new device.

The 16-bit organisation uses one less address bit, so the excess clock pulse might cause the first output bit to occur within the second SPI return byte, rather than the third. Are the 7-bits that are returned in the third byte, left or right justified?

Regards,
Mac

[eexpress]

thanks, Mac

good analyse. really i never thought about some manufactory maybe provide this serial chip without ORG(fixed to 8 or 16 address). the third byte returned is shift right one bit. and ORG pin is connect to GND on my PCB.
but this could not explain why the write part is OK, since i had verified this write part. the write part code is similar like read part as i posted.
now i have ordered sample chips from several manufactory, to take further test.

thank, you give me an good idea. perhaps, this could lead to right way.

[bigmac]

Hello eexpress,

---

eexpress wrote:

since 93c56 is raising CLK shift in, and falling CLK shift out, and the SPI is all raising SPSCK shift in/out current bit. it seems some critical state when MISO data shift in. or the status just like SPSCK lost the last half edge(one falling edge) at end.

---

I do not know how you have set up the CPOL and CPHA parameters for the SPI.  However, here is where I think the problem may now lie, after close scrutiny of the EEPROM data sheet -

First, let's assume that CPOL = 0, which is consistent with the EEPROM requirement.  Since the EEPROM samples DI on the positive clock edge, the setting CPHA = 0 is the appropriate setting for the sending of start bit, command bits, and address. Here, the MSB data is present at MOSI prior to the first clock edge, and changes on each negative clock edge thereafter. 

However, when it comes to reading the returned data at DO (MISO), the EEPROM outputs a dummy zero bit starting near the negative clock edge of the last address bit, and then changes to the first data bit after the next positive clock edge, and each subsequent positive edge.  Hence, the data should be read by the SPI on each negative clock edge.  This will require that CPHA =1 (CPOL remains at zero), the opposite setting from previously.

So this situation would require the CPHA setting to be changed between the sending of address data to the EEPROM, and the reading of the returned data byte.  This would only affect the READ process.  I presume your existing code does not alter the setting, and I can only assume that you are actually reading the dummy byte on the first positive clock edge of the read transaction.  This shows up a significant difference between Microwire and SPI.

Anyway, that is the theory - you will need to test it.

Regards,
Mac

[eexpress]

thanks, Mac

I really did those step, but not CPHA, just CPOL.

I also changed CPOL after sent address within my read programme. It seems not work. I thought maybe the change does not take effect due to SPI was enabled. And I dare not stop SPI when change CPOL. So I gave up the attempt.

CPHA, I will try.

thanks again.

[bigmac]

Hello eexpress,

I think that CPOL = 0 should remain for the whole sequence to avoid any discontinuity.  If you should find it necessary to disable the SPI, and then re-enable it, at the transition before reading the return bits, this should be OK provided the underlying I/O for the SPI clock pin has been previously set as an output, and for logic low.  The EEPROM will wait for the next clock edge, even if it is delayed.

Regards,
Mac

[eexpress]

Hi, Mac

I get the EEPROM works.
1. CPHA=0 at initialize.
2. CPHA change to 1 and back to 0, when read byte.

I also try this. just a test.
1. CPHA=0 at initialize.
2. CPOL change to 1 and back to 0, when read byte.

It also works well. That seems the error was come from CPHA initial value. For I thought CPHA is zero when reset.

Now all waves matchs the theory: raising edge shift in command, falling edge shift out data.

thanks Mac.

[bigmac]

Hello eexpress,

I think that your problem is that the 93C56 device is not actually a SPI compatible.  The SPI uses multiples of 8-bits.  However, with the 93C56, assuming you are using 8-bit organisation, a read command consists of one start bit, two command bits, and 9 address bits, a total of 12 bits.  Not sure how you organised this with the SPI.  Eight data bits are then returned, but these are preceded by a dummy bit - if this is what you are observing, you are probably one clock pulse short.  So the situation becomes very "messy".

I have previously used the 93C56, but have always used the bit-bang approach, without any problem.  Of course, this is considerably slower than the SPI.  I could provide assembly code if you are interested.

Another solution is to use SPI compatible EEPROM, such as the 25Cxxx series.  The smallest is probably the 25C080, an 8-kbit device (four times the capacity of the 93C56).  This is probably the cleaner method.

Regards,

Mac