I am using I2C and I have earlier posted doubts about I2C here. I am using PIC controllers and using their compiler C18. I used their libraries to build a function to write data in EEPROM via I2C, and when I crosschecked the SCL lines they were fluctuating.

I have made up a function to write to EEPROM but I have missed out on delays as the datasheet says "minimum 5ms delay for each write operation in to I2C is required".

I trust it is causing the troubles. The problem is SCL does not stay at 100kHz and fluctuates between 54kHz and 100kHz but never beyond that. Is that because Control byte,address and data is sent along the function?

float ee_write_float(unsigned char ee_addr, float f)
     void i2c_init(); //initialize I2c
     unsigned char *p = (unsigned char *)&f;
     unsigned char  i;

   for (i = sizeof f; i != 0; --i)
      EEByteWrite(EE_I2C_ADDR, ee_addr++, *p++);


How important is the dela for I2C write operations?

Could that be the cause of problem?

Should I put a delay after the EEByteWrite function to compensate?

Noted: the SCL becomes somewhat stable after the baud rate is reduced to 20kHz then it fluctuates between 17kHz and 19kHz. I would be extremely happy if you found out any reasonable cause to fix this trouble..or any valuable suggestions will be welcomed whole heartily.

  • 1
    \$\begingroup\$ I have to ask if you know a 5mS delay is specified in the datasheet why not try it? It's quite a long delay and at the moment you're probably be trying to write over a thousand times faster than allowed. \$\endgroup\$ – PeterJ Nov 25 '13 at 6:16
  • \$\begingroup\$ Well I'm trying to write at 100kps..but scl line when observed on scope showed..fluctuations and never stayed constant at 100kbps when i run the above function in main(). \$\endgroup\$ – Rookie91 Nov 25 '13 at 6:20
  • \$\begingroup\$ It could be clock stretching as proposed in an answer on the other question (I don't know much about that) but you'll need the 5mS delay eventually for it to work reliably. You could always use a trigger on the scope to capture the 100kbps clock even with the delay. How are you measuring the frequency? Maybe it's just jitter between bytes being transferred. \$\endgroup\$ – PeterJ Nov 25 '13 at 6:25
  • \$\begingroup\$ Yup I'm using the trigger button on the scope.Well the frequency just shows down..under the scope. OK..So it can be a jitter between bytes.Well i have put it under for loop..continuously. \$\endgroup\$ – Rookie91 Nov 25 '13 at 6:31
  • 1
    \$\begingroup\$ You're interpreting things to arrive at the problem that your I2C clock is unstable. So far as I know, clock stability is not guaranteed under the I2C standard. What is the REAL problem? Unreliable communication? \$\endgroup\$ – Scott Seidman Nov 25 '13 at 11:49

In I2C, the clock only toggles as necessary to transmit or receive data. There's no need for a continuous clock signal so variation in the observed frequency should be expected. The 100kHz specification is the maximum clock rate rather than the average or continuous clock rate.

Non-volatile memories like Flash and EEPROM need a relatively long period of time to write data into the memory, and 5ms sounds about right. You must not try to execute multiple write operations without allowing for this delay between them. Because of this, you cannot possibly execute more than 200 write operations per second and still allow 5ms per operation.

Once you have everything working correctly, you should expect to see a burst of 100kHz clock pulses every 5ms or so.


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.