PIC24 I2C issue

[diyaudio]

Hi Guys

I have a issue with getting my I2C bus to transmit data on the PIC24FJ128GB210, no clock or data is present its probably a configuration issue that I haven't considered. I checked the datasheet and all seems okay from what I read. I didn't check the errata for the PIC24FJ128GB210 cannot seem to find it.

Here are the code snippets.

Code: [Select]


// Clock is 16mhz, fcy = 8mhz

// make TRISA14, TRISA14 inputs.
TRISAbits.TRISA14 = 1;
TRISAbits.TRISA15 = 1;

// map SDI2 AND SCK2
PPSUnLock;
     iPPSInput( IN_FN_PPS_SDI2, IN_PIN_PPS_RPI35  );   
     iPPSInput( IN_FN_PPS_SCK2IN, IN_PIN_PPS_RPI36  );
PPSLock;


// Im sending test data as a test in the loop.
void main()
{
    __delay_us(100);
    // send data
    data_send_i2c();
}

void data_send_i2c(void)
{
    // 1) Master sends STart //
    CloseI2C2();                // Disable I2C1 mdoule if enabled previously

    unsigned int config1 = (I2C_ON  | I2C_7BIT_ADD );
    unsigned int config2 = 78; // I2CxBRG 100kHz bus with 16MHz oscillator
    OpenI2C2(config1,config2);  // configure I2C1

    IdleI2C2();
    // 1) Master sends STart
    StartI2C2();
    while(I2C2CONbits.SEN );  // Wait till Start sequence is completed
    MI2C2_Clear_Intr_Status_Bit; // Clear interrupt flag

    // 2) Master sends Slave ADdress with Write bit set //
    MasterWriteI2C2( 0xff );       //Write Slave address and set master for transmission
    while(I2C2STATbits.TBF);     //Wait till address is transmitted
    while(!IFS3bits.MI2C2IF);    //Wait for ninth clock cycle

  // dont ask the slave for any ack this is a test ? see anything on the scope yet???

}


This issue was keeping me busy all weekend with no luck. Please help.

[jmag999]

It looks like you are mapping SPI ports to those pins.  I2C pins do not go through the PPS matrix.

[diyaudio]

It looks like you are mapping SPI ports to those pins.  I2C pins do not go through the PPS matrix.

i see what you mean I corrected the problem and removed the PPS as suggested and used PINS 58 , 59.


used the pins see attachment. still no luck. bah!

[jmag999]

Next problem is that you are calling the I2C(2) functions, but your hardware is attached to the I2C1 peripheral.

[diyaudio]

Next problem is that you are calling the I2C(2) functions, but your hardware is attached to the I2C1 peripheral.

I have no hardware connected.. only the scope on pins 58 and 59 as i just want to verify the clock and data. any data nothing important yet. 

[jmag999]

Take a look at the pin names on the pinout you attached on the first post.  It shows SCL1 and SDA1.  This means that you are connected to I2C port 1.  But your code is writing to I2C port 2, because you are using functions like IdleI2C2();.  Change them to xxxxI2C1() and it should work.

[diyaudio]

Take a look at the pin names on the pinout you attached on the first post.  It shows SCL1 and SDA1.  This means that you are connected to I2C port 1.  But your code is writing to I2C port 2, because you are using functions like IdleI2C2();.  Change them to xxxxI2C1() and it should work.

I have moved it to pins 58, 59 which should be the correct I2C-2 peripheral the first time it was incorrect. now the code is referencing I2C2. see the previous attachment. 
   

[diyaudio]

still no luck. gosh im starting to doubt the #include "spi.h" library does it even work.

[jmag999]

Do you have pull-ups on the bus?

[granz]

Do you have pull-ups on the bus?

Was literally just writing that same thing.  The PIC I2C outputs are open-drain type, so you'll get nothing with just the scope connected and no pull-ups.

[diyaudio]

Do you have pull-ups on the bus?

@jmag999, @granz

Thanks guys, its working correctly now, I used a 4.7k pull-up. it works. nicely.
 

[dannyf]

If the sender / receiver pins have pull-up, you may be able to get by with that.

[granz]

If the sender / receiver pins have pull-up, you may be able to get by with that.

I believe enabling the I2C pins overrides all other peripherals including the regular I/Os, and the internal pull-ups are part of the change-notification circuitry for regular I/Os.  Anyhow, the internal pull-ups are of the weak variety, and not suited for I2C...