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.

i2c both lines stay low - tm4c1294xl

Hello,

I am using a tm4c1294 microcontroller, which is cortex m4 based. I m not very sure if the problem is software or hardware related. My goal is to be able to communicate with the tcs3472 loght sensor.

The problem is both of my lines (sda and sclk) stay low. picture: http://imgur.com/bFlQlY4

I don't think this is clock stretching. I only put two pull up resistors of 10k to 3.3v. But I think that normally I should at least see the address being sent with a NACK or ACK and afterwards my data, no?

this is my code:

   #define I2C7Master_Base 0x400C3000

   void setupI2c();
   void sendTestCmd();

   int main(void)
    {
        setupI2c();
        while(1){
        sendTestCmd();}
    }

    void setupI2c()
    {
        SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
        SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C7);
        GPIOPinTypeI2C(GPIO_PORTA_BASE, GPIO_PIN_4|GPIO_PIN_5);
        I2CMasterInitExpClk( I2C7Master_Base, SysCtlClockGet(), false);
        I2CMasterSlaveAddrSet(I2C7Master_Base, 0x29, false);
        I2CMasterEnable(I2C7Master_Base);
    }

  void sendTestCmd()
  {
    I2CMasterDataPut(I2C7Master_Base, 0x55);
    I2CMasterControl(I2C7Master_Base, I2C_MASTER_CMD_SINGLE_SEND);
    while(I2CMasterBusy(I2C7Master_Base))
    {
           //WAITS FOREVER
    }
  }

Thank you

  • Hi,
    Use GPIOPinTypeI2CSCL() for the SCL pin. You're also missing the GPIOPinConfigure calls to actually route the I2C signals to the pins.

  • More than your identification - poster (appears) to be employing (ancient) Stellaris function calls - from LM3 devices - prior to Tempest. Those early MCUs had no provision to accept "GPIOPinConfigure()" functions.

    Vendor needs to do far better job to "steer users" away from inappropriate code blocks.   (or instead - we can encourage & entertain 24 bit ADC implementation by (apparent) neophytes - with little chance for success.)    (i.e. NONE!)

    Perhaps not to fiddle - while Rome burns...  

    Let the record show that multiple "outsiders" have provided "cover" for vendor's "escape" from a meaningless (time-eating) thread... (and the wild west continues...)

  • Good catch - didn't see that. As I said somewhere, I've only been around this neighbourhood since the LX4F...
    Then again, is there anything but ancient software available even for the TM4C right now? :-)
  • We use (exclusively) that "ancient" yet "bug-free" and long tested/proven earlier software. (w/LM3S and LX4F...)
  • Thank you very much for your reply, but it still doesn t work

    My new code:

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOA);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C7);
    GPIOPinConfigure(0x00001002);
    GPIOPinConfigure(0x00001402);
    GPIOPinTypeI2C(GPIO_PORTA_BASE, GPIO_PIN_5);
    GPIOPinTypeI2CSCL(GPIO_PORTA_BASE, GPIO_PIN_4);
    I2CMasterInitExpClk( I2C7Master_Base, SysCtlClockGet(), false);
    I2CMasterSlaveAddrSet(I2C7Master_Base, 0x29, false);
    I2CMasterEnable(I2C7Master_Base);

    I2CMasterDataPut(I2C7Master_Base, 0x55);
    I2CMasterControl(I2C7Master_Base, I2C_MASTER_CMD_SINGLE_SEND);
    while(I2CMasterBusy(I2C7Master_Base));
  • OW I just reset my microcontroller a few times (not just once), and now this works!

    But I get strange data, no matter what I send as data this is what I get when I send 0x55 or 0x01
    http://imgur.com/wIq9bl4

  • Well it most certainly does not work. SDA should have the first transition (START condition on the bus), so are you absolutely certain that you haven't got the pins in the wrong order in your Saleae?

    But your code still reveals that you're not "up to date" with your calls - for example the values to GPIOPinConfigure would be better expressed as GPIO_PA4_I2C7SCL etc (do check from pin_map.h, I'm going off memory). Also, you say you're working with TM4C129, yet you call SysCtlClockGet() which only works for TM4C123 devices. I think you should read the driver library manual. (tivaware/docs/SW-TM4C-DRL-UG-version.pdf)

    Also, have you watched the LaunchPad videos and checked the TivaWare examples in examples/peripherals/i2c? It's better to first check that you can successfully run one of the proven examples before trying your own wings.
  • It also (and often) proves wise to "break any/all" connections to external devices - just in case - during early test/verify.
    You'll die at the absence of ACK/NAK - but at least give the MCU its full chance to emit proper code burst...