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.

TM4C123GH6PM: UART stops working after enabling I2C module.

Part Number: TM4C123GH6PM

I have a Modbus application running on the TM4C123GH6PM, which uses the debug UART port (UART0) for communication with a Windows-side master. The Modbus application has been tested and works well. Now I would like to add I2C communication with an external ADC (the TI ADS 1110). However, when I enable the I2C module, the Modbus communication (UART) stops working. I have debugged the application, and Modbus only stops working when I2C is enabled. Here is my GPIO configuration:

Here is my UART configuration:

And here is my I2C configuration:

My guess is that it has something to do with the use of the system clock by both modules, but I'm not certain what I can do to fix it. The clock is configured to 50 MHz:

Many thanks,

Ksawery 

  • Greetings,

    Perhaps this helps:  (extracted from vendor supplied I2C example)

    // Configure the pin muxing for I2C0 functions on port B2 and B3.
    //
    GPIOPinConfigure(GPIO_PB2_I2C0SCL);
    GPIOPinConfigure(GPIO_PB3_I2C0SDA);

    //
    // Select the I2C function for these pins. This function will also
    // configure the GPIO pins pins for I2C operation, setting them to
    // open-drain operation with weak pull-ups. 
    //
    GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_2);     
    GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);             *** This call is 'AWOL' due to the errant call - above!

    Note that  your code (line 69) reveals:

    GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_2 | GPIO_Pin_3);      *** You have combined both PortB pins w/in this call - have you not?

    And that's 'illegal' - is it not?    (Das est  Verboten!)

    And:  GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);             *** This call is 'AWOL' due to the errant call - above!

    Test is 'Quick/Dirty' (i.e. My kind of test) and (likely) resolves.    (I cannot explain how/if your I2C - under 'your' code - ever worked!   IF it ever worked!)

    I cannot explain - 'How or Why' the enabling of the I2C module 'KILLS' the UART's operation.   But as always - best to, 'FIX the KNOWN ISSUES FIRST' - and (later) deal w/(other complaints/details...)

  • Thank you, well spotted. I didn't realize you had to setup the pin type for SCL and SDA lines separately. I made the  changes you suggested, however the UART still stops working when I2C is enabled. Here is my updated code:

    Regards,

    Ksawery

  • Thank you - yours proves an, 'Excellent & Encouraging  INSTANT Response!'   (So rare w/in this increasingly 'desolate plain.')

    Might you - at least temporarily - switch to 'another' I2C Port - and Re-Test.   (Sorry - but this (may) prove insightful...)

    Like you - I cannot fathom the 'How/Why' of  such "Inter-Module" sensitivity.   Use of that separate I2C module may enable you to 'Escape this issue' - and 'Who really cares' - why this occurs?   (Really!)

    Is yours an "LPad?"   If so - beware the LONG (and UNCORRECTED) pair of 'Plague-Istors'  (aka R9/R10) - so nicely 'shorting' PD0-PB6 & PD1-PB7!   (for years I've (so gently) suggested that those 2 be 'bagged' for the (so rare) instance when past MSP compatibility IS desired!

    I always advise that 'any/all' I2C APPS employ (real) hardware added pull-ups - and not rely upon the (50KΩ+) internal, MCU resistors.

    Is it certain that your ADC - if mounted to another board - shares a common GROUND - and receives adequate (i.e you've MEASURED) Power?   

    Might it be that 'BEYOND JUST YOUR UART' has GONE QUIET - when I2C is enabled?

    [edit]   HOLD THE PRESSES - I CANNOT SEE  WHERE YOU'VE ENABLED THE UART!    PORT A IS ENABLED BUT THAT'S INSUFFICIENT!

  • Thank you, I believe I found the bug. The following line was:

    SysCtlPeripheralEnable(I2C0_BASE);

    Instead, it should have been:

    SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C0);

    In addition to your help, that solves the issue.

    Regards,

    Ksawery

    Edit: The UART is enabled and configured elsewhere in the application (as shown partially in the initial post). It has been thoroughly tested and works ok.