A problem shared is a problem halved !
I have spent several hours over the last few days, chasing an I2C problem , What should have been straight forward ..adding my I2C 2x8 LCD display code from PIC24F to a PIC 24EP , turned into an in-depth de-bug of I2C protocol... no problems with my I2C driver previously it works fine with PIC24F, EEPROM , DS1307 , this display and other slave PIC's …. until .
The setup, MPLABX 3.26 XC v1.26 Pickit3 PIC24EP256MC204 16Mhz internal (8MIPS) MIDAS I2C lcd display
The relevant C code...
The start and device address shown is the eventual work around
This is what a Bus pirate made if the signals …
start bit , 0x7C , and the slave ACK... the check is done during the low STATUS trace.
Getting here...
The first run of code and my usual test for I2C1STAT.ACKSTAT … failed . To cut a lonnnnng story short, seems with this PIC24EP and dsPIC33EP any read of the I2C1CON or I2C1STAT registers during I2C operation prevents correct ACK detection, ACK=0 NACK=1 .. actually I never saw a 0 whatever I tried and I tried everything ! After reading posts on MC forum decided I could not poll the ACKSTAT bit, MC data sheet suggested using the master MI2C interrupt, but that happens for the start bit and the TX status, and interrupted way after the 9th clock and ACK long since gone . Determined to solve my problem, I bypassed the SDA , ACK detection and used a second IO input RC3 on the data line, waited for the TX buffer to clear tested the ACK from the slave and after a __delay_us(20) ( required by LCD) sent next byte... Bingo...
As I said posts on the MC forum ( not a favourite site !) turns out I am not alone with this bug . The MC note DS80526c errata for the dsPIC33EP hints at this problem , but I think they missed a bit out. !
I have spent several hours over the last few days, chasing an I2C problem , What should have been straight forward ..adding my I2C 2x8 LCD display code from PIC24F to a PIC 24EP , turned into an in-depth de-bug of I2C protocol... no problems with my I2C driver previously it works fine with PIC24F, EEPROM , DS1307 , this display and other slave PIC's …. until .
The setup, MPLABX 3.26 XC v1.26 Pickit3 PIC24EP256MC204 16Mhz internal (8MIPS) MIDAS I2C lcd display
The relevant C code...
Code:
void I2C_start(unsigned char device_addr)
{
I2C1CONbits.SEN = 1; // Set start bit
while(I2C1CONbits.SEN){} // and wait
I2C1TRN = (device_addr << 1) & 0xFE; // send (slave + write bit )
while (I2C1STATbits.TBF){} // wait I2C buffer
I2Cackstat(); // test ACK
}
void I2C_sendB(unsigned char data)
{
I2C1TRN = data; // send byte
while (I2C1STATbits.TBF){}
I2Cackstat();
}
void I2Cackstat()
{
LATBbits.LATB9 = 0; // START STATUS
if(PORTCbits.RC3) // connected to SDA
{
I2C_ERR(); // go fix it
}
while (I2C1STATbits.TRSTAT){} // I2c frame finished at 9th clock
__delay_us(20);
LATBbits.LATB9 = 1; // END STATUS
}This is what a Bus pirate made if the signals …
start bit , 0x7C , and the slave ACK... the check is done during the low STATUS trace.
Getting here...
The first run of code and my usual test for I2C1STAT.ACKSTAT … failed . To cut a lonnnnng story short, seems with this PIC24EP and dsPIC33EP any read of the I2C1CON or I2C1STAT registers during I2C operation prevents correct ACK detection, ACK=0 NACK=1 .. actually I never saw a 0 whatever I tried and I tried everything ! After reading posts on MC forum decided I could not poll the ACKSTAT bit, MC data sheet suggested using the master MI2C interrupt, but that happens for the start bit and the TX status, and interrupted way after the 9th clock and ACK long since gone . Determined to solve my problem, I bypassed the SDA , ACK detection and used a second IO input RC3 on the data line, waited for the TX buffer to clear tested the ACK from the slave and after a __delay_us(20) ( required by LCD) sent next byte... Bingo...
As I said posts on the MC forum ( not a favourite site !) turns out I am not alone with this bug . The MC note DS80526c errata for the dsPIC33EP hints at this problem , but I think they missed a bit out. !
Last edited:
