This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28027: Slave I2C problem

Part Number: TMS320F28027
Other Parts Discussed in Thread: C2000WARE

Hi guys, I'm trying to use my C2000 launchpad featuring a TMS320F28027 as an I2C slave. My interrupt routine never seems to be triggered.I created a global variable that is supposed to be incremented by 2 every time I go in the routine. I look at the variable using the  By looking to my code I do not find what could possibly be wrong. 

Does anyone have an idea?

Thank you guys !

  • Hi Amine,

    I think part of your description is missing or got cut off.

    How are you going about testing this? i.e. do you have a master device addressing the slave and writing to or reading bytes from it?

    How are you confirming that the interrupt is indeed not entered? i.e. maybe putting a breakpoint in the ISR and never getting there... Have you been checking waveforms on the SDA & SCL lines to make sure the communication looks like what you are expecting? If so, can you provide screenshots for me?

    Best,
    Kevin
  • Hi Sir, so I modified a little bit my code.Below is the new version. 

    My tests are still not working.. I put a breakpoint in the ISR but I never seem to go into it. I added capacitors of 47pF. I thought this might help but still nothing..

    I'm using a Aardvark module, which is an USB/I2C converter. I checked the waveforms of my communication ( see below too) with a logic analyzer and everything seems fine, my MCU just seems to be not responding to any command.. 

    Thank you for the help !

  • Hi Amine,

    Thanks for providing the waveform. It looks like the comms from the master are good, assuming this is being probed at the slave interface (i.e. the signal seen at the slave matches this). The slave address is correct, but the slave doesn't ACK for some reason...

    Could you try enabling I2caRegs.I2CMDR.FREE = 1 and see if that fixes the issue?

    Also, can you try following the initialization process in the i2c_eeprom example in C2000ware as much as possible? Maybe some of the initialization is out of order and causing issues.

    C:\ti\c2000\C2000Ware_1_00_05_00\device_support\f2802x\examples\structs\i2c_eeprom

    Best,
    Kevin
  • Hi sir , I've tried both what you said and still nothing is working..
    This issue is getting really painful...
  • Hi Amine,

    Can you double check that you're using the correct GPIOs for your board? Also, can you try replicating the way the example sets up the GPIOs and maybe even use the same ones?

    InitI2CGpio()
    {
        EALLOW;
    
        //
        // Enable internal pull-up for the selected pins
        // Pull-ups can be enabled or disabled disabled by the user.
        // This will enable the pullups for the specified pins.
        // Comment out other unwanted lines.
        //
        GpioCtrlRegs.GPAPUD.bit.GPIO28 = 0;    // Enable pull-up for GPIO28 (SDAA)
        GpioCtrlRegs.GPAPUD.bit.GPIO29 = 0;    // Enable pull-up for GPIO29 (SCLA)
    
        //GpioCtrlRegs.GPBPUD.bit.GPIO32 = 0;   // Enable pull-up for GPIO32 (SDAA)
        //GpioCtrlRegs.GPBPUD.bit.GPIO33 = 0;   // Enable pull-up for GPIO33 (SCLA)
    
        //
        // Set qualification for selected pins to asynch only
        // This will select asynch (no qualification) for the selected pins.
        // Comment out other unwanted lines.
        //
        GpioCtrlRegs.GPAQSEL2.bit.GPIO28 = 3;  // Asynch input GPIO28 (SDAA)
        GpioCtrlRegs.GPAQSEL2.bit.GPIO29 = 3;  // Asynch input GPIO29 (SCLA)
    
        //GpioCtrlRegs.GPBQSEL1.bit.GPIO32 = 3;  // Asynch input GPIO32 (SDAA)
        //GpioCtrlRegs.GPBQSEL1.bit.GPIO33 = 3;  // Asynch input GPIO33 (SCLA)
    
        //
        // Configure I2C pins using GPIO regs
        // This specifies which of the possible GPIO pins will be I2C 
        // functional pins. Comment out other unwanted lines.
        //
        GpioCtrlRegs.GPAMUX2.bit.GPIO28 = 2;   // Configure GPIO28 for SDAA
        GpioCtrlRegs.GPAMUX2.bit.GPIO29 = 2;   // Configure GPIO29 for SCLA
    
        //GpioCtrlRegs.GPBMUX1.bit.GPIO32 = 1;   // Configure GPIO32 for SDAA
        //GpioCtrlRegs.GPBMUX1.bit.GPIO33 = 1;   // Configure GPIO33 for SCLA
    
        EDIS;
    }

    Please explain how you are enacting this test. The program is in the infinite loop waiting to see its slave address before the master begins transmitting correct?

    Best,

    Kevin

  • Hi Sir, 

    I configured my GPIO's just like Manoj proposed me in this thread and still nothing..

    This is correct, my slave is in infinite loop waiting to receive something from the master. I send data( I'm a 120% sure my sending is correct, I've tried the device i'm using with multiple other boards and it works fine) and my interrupt never triggers..

    I'm not sure I can use the init GPIO of the example because they call a function called Init GPIO but I did not find anywhere the definition of this function .

    thank you for the help.

    Amine

    Thank you for the help.

  • Hi Amine,

    Please follow Manoj's GPIO configuration exactly except with the following change:

    GpioCtrlRegs.GPBQSEL1.bit.GPIO32 = 3;     // Set to 3 for async

    GpioCtrlRegs.GPBQSEL1.bit.GPIO33 = 3;

    If that doesn't fix the issue please try turning on FREE mode within your I2C init function:

    I2caRegs.I2CMDR.bit.FREE = 1;

    Hope this helps,

    Kevin

  • Hi sir, I modified the GPIO's.

    My free bit was also previously set. But still nothing.. Interrupt never triggers

  • Hi Amine,

    When you captured the provided logic waveforms were you probing at the slave interface? I'm curious if the communication is somehow getting corrupted before reaching the slave device, being that no ACK is received after the slave addressing portion.

    Could you try your test without enabling interrupts? I would recommend focusing your efforts on successfully addressing the slave device, i.e. slave address is followed by an ACK instead of a NACK.

    Best,
    Kevin