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
// 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(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...
I2C2 clock speed is ~33KHz (same as bit banged code)
PIC24FJ64GA002 uses external 18.432MHz crystal
Silicon is new Rev B4