• AVR Freaks

Hot!I2C2 delay

Author
MaccorFW
Starting Member
  • Total Posts : 54
  • Reward points : 0
  • Joined: 2008/05/13 06:08:24
  • Location: 0
  • Status: offline
2008/12/17 07:02:03 (permalink)
0

I2C2 delay

Just posting this to see if anyone else has noticed the same situation.  The guys at the factory are looking into it, but it always helps to ask other users..
In working on initial I2C2 code for a PIC 24FJ64GA002 (DIP pkg), I am seeing a timing delay between the first two bytes:
Using the CLK signal as a time reference, the Address(Wr) byte is OK, including ACK.  The C/R (Command/Register) byte however, is not clocked out for 3ms... 
Comparison with other "bit-banged" code & HW connected to the same device shows the time between the completion of the Address(Wr) ACK clock and the first clock of the C/R bit is <200us. Using another port bit for timing, the delay was found to be in waiting for the TRSTAT bit after sending the C/R byte.  There is also an additional delay of about 308us between the clocking out of the C/R byte bits until the ACK clock is sent,  For the Address(Wr) byte, it's ACK clock immediately follows the clocked data, as normal. 
The code is as follows (comments added):

I2C2TRN=addrs; // send it out
while (I2C2STATbits.TRSTAT); // wait until Tx is done
// check for ACK
while(I2C2STATbits.ACKSTAT); // Correctly detected & instruction passed very quickly

// check for Tx buffer empty // This made no difference
//while(I2C2STATbits.TBF);

// Address acknowledged, so send a command/register value
I2C2TRN=Command; // send it. (takes 3ms for clocking to start)

// timing signal added (scope ignal rise starts right after Address(Wr) ACK clock)
LATA=0x0001; // Timing signal on
while (I2C2STATbits.TRSTAT); // ~3ms delay before clocking starts
LATA=0x0000; // Timing signal off

// additional ~308us from last command/reg bit's clock until ACK clock sent. Correct ACK detected.
while(I2C2STATbits.ACKSTAT);

Send_I2C2_stop();
while(1); // for debugging...

Since the TRSTAT bit indicates the Address transmission is done, the I2C2TRN should accept the next byte and immediately start clocking out data...

Notes:
I2C2 clock speed is ~33KHz (same as bit banged code)
PIC24FJ64GA002 uses external 18.432MHz crystal
Silicon is new Rev B4

Comments?

#1

3 Replies Related Threads

    MaccorFW
    Starting Member
    • Total Posts : 54
    • Reward points : 0
    • Joined: 2008/05/13 06:08:24
    • Location: 0
    • Status: offline
    RE: I2C2 delay 2008/12/17 15:29:38 (permalink)
    0
    Found it.
    Proves to not be a significant issue-- turns out the delay only occurs on the first operation after the I2C peripheral is initialized.

    #2
    allenhuffman
    New Member
    • Total Posts : 14
    • Reward points : 0
    • Joined: 2019/10/08 12:22:42
    • Location: Des Moines, Iowa, USA
    • Status: offline
    Re: RE: I2C2 delay 2019/11/19 08:00:27 (permalink)
    0
    I just found that the 24FJ64GA002 in Slave mode does not see the first Start bit and Event Interrupt Flag Status bit from the Master. It looks like some quirks in this chip may go back some time.

    Allen C. Huffman, Sub-Etha Software (est. 1990) www.subethasoftware.com
    Embedded C, Arduino, ESP8266/32, BASIC Stamp and PIC programmer.
    #3
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3370
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: online
    Re: RE: I2C2 delay 2019/11/19 09:09:05 (permalink)
    1 (1)
    11 Years, same age as my i7-920.

    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #4
    Jump to:
    © 2019 APG vNext Commercial Version 4.5