Hallo!
H/w I use is 24LC512 5V I2C EEPROM. The chip is connected to the C167. The only I2C data line pulled-up via 5 kOhm resistor (clock line is not). Vcc connected to ground via 0.1 uF. Clock rate is about 125 kHz. I have no trouble neither with byte write, page write, random read operations driven via pin-bang routines. However I stucked on sequential read access when migrated to it from singe byte mode.
I use uVision Keil debugger and even in static go-through step-by-step manner still experience problem with reading 2nd, 3d, etc. bytes (the 1st byte is OK) - all I read is just FFh, i.e. data line being held high. My f/w does issue data, ACK/NOACK and clocks according to I2C specs (see below).
WHEN I connect scope probe to the data and clock lines to watch the waveforms, everything becomes OK, i.e. instead of FFh I get what should be! It remains to be OK if I hold scope's probe only at data line pin (i.e. seems this is OK to have no pull up at clock line at least in this particular case). As soon as I disconnect probe, I return back to trouble. With probes attached I see waveform timing is perfect and data are what I expect (I see them also in debugger).
So, I touch data pin with probe - good, disconnect the scope - have trouble.
Any idea what can cause the problem (might it be a purely electrical issue)?
Thanks, Nikolay.
Here is the follow-up to the subj.
The problem was solved by putting 8.2 kOhm resistor instead of 4.9 kOhm as pull-up for data line. Nothing other was changed. It works now for at least up to 200 kHz. Some other experiments were carried out. Here is an overview in form of "truth table":
+----------------+--------+----------+----------+---------+ | Pull-up @ data | 1 kOhm | 4.9 kOhm | 8.2 kOhm | 22 kOhm | +----------------+--------+----------+----------+---------+ | no scope probe | FAIL | FAIL | OK | OK | +----------------+--------+----------+----------+---------+ | w/ scope probe | FAIL | OK | OK | FAIL | +----------------+--------+----------+----------+---------+
Unexpected is that this is higher value for pull-up resistor which has helped. Well..., the 22 kOhm was put purely dure to curiosity. Changing capacitor to 1.0 uF instead of 0.1 uF between chip's Vcc and GND did not help.
Again, sequential write and random read of a single byte routines were working just fine all the time (for 4.9 kOhm), and it was sequential read operation that failed after the 1st byte is read.
For sequential read MCU has to change data line direction; on the other side the MCU checks clock line each clock for possible clock stretching, i.e. direction of clock line is changed even for sequential write operation.
The h/w is soldered on 10-layer PCB w/ standard form-factor 12x24 cm. However the EEPROM is placed onto side opposite to the MCU, no more details on tracing available.
P.S. Would greatly appreciate somebody who can give an distinct/clear explanation of observed behavior.
Regards, Nikolay.
More on troubleshooting. Finally the 'strange' behavior is explained and root reason found; an extensive test with random numbers being write/read sequentially over 32 kB of the EEPROM space has helped. Simpler tests may not uncover the problem. Stronger tests proved the solution listed at previous post was just masking the situation.
Actual reason for sequential read to fail turned out to be trivial and is because of incorrect moment of time where data line direction was changing to input from output in two subsequent routines where master a) sends the acknowledge ACK to the slave (EEPROM), and b) later on tries to read data from the slave.
I.e. ACK sequence shown below in pseudocode works just fine but with line (*) commented out the routines start to malfunction due to the fact the chip may get false STOP condition (while clock remains HIGH with data line flipping to input being pulled up):
the acknowledge routine (a) clock= LOW clock direction= OUTPUT data line= LOW data dir= OUTPUT DELAY clock= HIGH DELAY clock= LOW (*) // must be before data line will change its direction DELAY (optional) the byte read routine (b) data dir= INPUT // read 8 bits clocking them in // read cycle starts ---> clock= LOW DELAY clock= HIGH DELAY read DATA pin // <--- the read cycle ends (8 bit in total)
Pull up resistor at data line returned back to its initial value 4.9 kOhm, and no influence of scope's probe observed as it should be.
P.S. By the way, the Microchip's datasheet ds21754E (year 2004) on 24LC512, page 7, figure 4-2 shows confusing (!) illustation which claims that this is at point <clock= HIGH> (before falling adge) receiver must release the SDA line.
Priceless war story!
I can imagine the argument:
Electrical Engineer: "- check your code!"
Firmware Engineer: "- check your resistor calculations!"
Bottom line, writing firmware is not an easy job, that's why I love it : )
Steph-