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.

TM4C129ENCPDT: I2C example, tmp006, doesn't not work on TM4C129EXL Launchpad

Part Number: TM4C129ENCPDT
Other Parts Discussed in Thread: EK-TM4C129EXL, TMP006

HI,

I am trying to get I2C interface to first just start up and send an initial master write request. At this point, only watching SCL and SDA at the Boosterpack header pins. There is no observed activity on either pin when the example is run in the debugger. The pins don't even get pulled high.

The example project was copied into CCS Version: 7.1.0.00016 via the CCS Resource Explorer, from folder TI-RTOS for TivaC-v:2.16.00.08\Development Tools\EK-TM4C129EXL\DriverExamples\I2C_Examples\I2C_tmp006.

The I2C is initiallized as follows:

void EK_TM4C129EXL_initI2C(void)
{
    /* I2C7 Init */
    /*
     * NOTE: TI-RTOS examples configure pins PD0 & PD1 for SSI2 or I2C7.  Thus,
     * a conflict occurs when the I2C & SPI drivers are used simultaneously in
     * an application.  Modify the pin mux settings in this file and resolve the
     * conflict before running your the application.
     */
    /* Enable the peripheral */
    SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C7);

    /* Configure the appropriate pins to be I2C instead of GPIO. */
    GPIOPinConfigure(GPIO_PD0_I2C7SCL);
    GPIOPinConfigure(GPIO_PD1_I2C7SDA);
    GPIOPinTypeI2CSCL(GPIO_PORTD_BASE, GPIO_PIN_0);
    GPIOPinTypeI2C(GPIO_PORTD_BASE, GPIO_PIN_1);

    /* I2C8 Init */
    /* Enable the peripheral */
    SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C8);

    /* Configure the appropriate pins to be I2C instead of GPIO. */
    GPIOPinConfigure(GPIO_PA2_I2C8SCL);
    GPIOPinConfigure(GPIO_PA3_I2C8SDA);
    GPIOPinTypeI2CSCL(GPIO_PORTA_BASE, GPIO_PIN_2);
    GPIOPinTypeI2C(GPIO_PORTA_BASE, GPIO_PIN_3);

    I2C_init();
}

This is called via Board_initI2C() from main in file i2ctmp006.c.

In a prior call, all the gpio ports are init via call to Board_init_GPIO and Board_initGeneral.

I have poked around the forums but have not seen any indication any of the above is incorrect; in fact i have to say based on what I have read so far, the above is correct.

Hope someone here can ask the right questions about what I'm doing that will lead to a solution.

Thank you in advance.

  • Did you provide pull-up resistors? From page 1402 of the data sheet:

  • Feel your pain - yet might (some) of it be, "self-inflicted?"     (i.e.  You've engaged both the MCU and an RTOS - the code shown reveals two I2C modules (w/out describing which one is failing) - and you report "probing for I2C signals at the Boosterpack, header pins.")     (it is always best to probe as close to the source of such signals as possible.)

    While the presence of (external) pull-up Rs will certainly assist (and always prove superior to the "too high" values provided by MCU's internal ones) would it not prove best to employ, "KISS" - and (temporarily) break your (assumed) multi-board connections - focus instead solely upon the "misbehaving" I2C port - without the burden of any RTOS?     The principle is that of, "Divide & Conquer" - the current "all at once" approach serves to "mask" the source & locations of your problem.    (which could be w/in the MCU, the RTOS, (even both) or the again (assumed) board to board interconnect.)

    Simplifying by reducing the "field of play" in this manner - best enables your systematic understanding of the component system parts (MCU, RTOS, interconnects) - and (only) when each one is, "individually test/verified" - should they be interconnected & employed as a team.      

    The more "variables & uncertainties" before you - the longer & more painful - your struggle.     "KISS" has long been well proven to aid your understanding - while leading to knowledge gains - even while proving the,  "fastest, most efficient, and easiest, "Issue Solution Vehicle!"

  • HI,

    Wow, thank you for the quick response.

    The following text from the TM4C129EXL Launchpad UG, Table  for each of the SCL signals:

    I2C module 7 clock. Note that this signal has an
    active pull-up. The corresponding port pin should
    not be configured as open drain.

    I assumed that at least the SCL line should be pulled high, if it is configured correctly, which I am assuming the example design does. So maybe the example isn't configuring the pullup on SCL???

    The Schematic section towards the end of the UG for this Launchpad is empty (no schematic) so I can't see where a pullup should be placed for either SCL or SDA. I am guessing after looking at the board, that no pads are provided specifically for this. I am thinking could dead-bug an R onto the board next to the appropriate header pin socket on the edge of the board (for connector X11) to wire in the pull-ups. Does this make sense?

    Thank you again for the response and happy 4th.

  • After some poking around, came across the board design files for this Launchpad here:
    www.ti.com/.../getliterature.tsp

    Looking at the schematic, I don't see any testpoints or other probe points. I think the BP and X11 header pins are it.
  • HI,

    Probed all 4 I2C ports that are connected to the BP headers. All showed no activity. Intent was to use I2C7 (PD0/1), which map to BP1 X9-12 and -14.

    Nothing is connected to the I2C; running the Launchpad board stand-alone. Just trying to get the first I2C address write to work, monitoring with DSO.

    After finally tracking down the board schematic (its missing from the Launchpad UG), I don't see any other place to probe these signals other than direct at uC pins (which i can hardly distinguish). Its possible but a real stretch (I think) that both SCL/SDA paths are not correctly routed on an eval board that TI is shipping.

    In reading thru the API documentation for I2C, somewhere I was lead to believe these API calls can only be used within TIRTOS. This design example from TI does just that. My post is regarding this design example. If there is some register setting not configured correctly the way it is written, I haven't been able to track it down yet. Will keep digging around. Am I naive to assume these design examples have been tested before they are "delivered" from TI?

    After I add pull-ups, if still no action, and baring any other discoveries about the API calls, will attempt a bare-metal version.

    Thank you for your input; really appreciate.
  • I should have mentioned that the application (running in debug) completes the initial transmit (stepping thru the code) and then blocks. ROV shows Idle Task running, and taskFXN blocked.
  • There is "great" merit in KISS - surgeons always "drape" the "operative area" - so that the extraneous does not intrude.     Your use of (both) the MCU and "hoped for" RTOS discards that "draping" - and leaves you (only) "hope" - that everything will fully & properly coordinate -and operate correctly.      (note that skilled/trained vendor agent - beat a retreat from your issue - does that not "reinforce" the notion of "overly complex?)

    Hundreds of posts land here - in each case - hallowed vendor cannot fully anticipate the user's modifications & import of "personal preferences."    Ratcheting up complexity - prior to "mastering the basics/specifics" - seems substantially counter-intuitive...

    Again - your "hope" for, "complex, multi-element, "turn-key" system success" has not materialized - thus my suggestion to, "limit the playing field" - which (at least) renders your trouble-shooting effort far less demanding!     (thus faster, easier, superior - far more likely to succeed.)

    Complex systems most always succeed via the adoption of, "Proceed by Refinement."       Your "counter" to that direction is, "Did not the vendor test adequately?      Your "difficulty" - arrives in (convincing) answer - does it not?

    Minus your investment of "time/effort/focus" - to truly understand the constituent parts - your long-term growth & success are "held hostage" to the "desire for "quick/easy" (i.e. minimal effort - vendor project) - which does not agree nor reflect the "normal/customary" human learning process...      "KISS" is your antidote - even as you resist - especially as you resist...

  • Adding the pull-up R's on the SCL/SDA signals did the trick. Start, address, write state, NACK (since no slave connected) and stop sequences all as expected. Thank you for the dope-slap. Now on to the real problem...
  • Screen capture of I2C Master to Slave address cycle.