• Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 606 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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 not working

Lin Wei Hung
Prodigy 190 points
Other Parts Discussed in Thread: EK-TM4C123GXL

Hello,

There is another questino confused me and ask your help,

 I use the EKS-LM4F2323 Evaluation Kit and try to measure the waveform of I2C channel 0 SCL and SDA,

Below is the source code and made the I2C0 as master to send a character,

There are no slave device to connect to the I2C0 and i only use the scope to measure the GPIOB PB2 and PB3

on the EKS-LM4F2323 Evaluation Kit but i can not see any waveform after send the date on the I2C0,

Does anything wrong with the operate or the source code ?

Any comment will be appreciated, thanks

ps : 1. in API GPIOPadConfigSet() if the parameter set GPIO_PIN_TYPE_OD_WPU, i only see the SDA pull high but  SCL keep in low

            I think there are no pull up resistor , am i right ?

       2.  in API GPIOPadConfigSet() if the parameter set GPIO_PIN_TYPE_STD_WPU, both the SDA and SCL will be pulled high but still can not 

             see the waveform in the scope after send the data, what is the really parameter should be setting in this API?

#include "inc/hw_memmap.h"
#include "inc/hw_types.h"
#include "inc/hw_i2c.h"
#include "driverlib/i2c.h"
#include "driverlib/sysctl.h"
#include "driverlib/gpio.h"
#include "utils/uartstdio.h"
#include "inc/lm4f232h5qd.h"


#define SLAVE_ADDRESS 0x3C

void main(void) {
    
    unsigned long reg='A';


    SysCtlClockSet(SYSCTL_SYSDIV_1 | SYSCTL_USE_OSC | SYSCTL_OSC_MAIN |
                           SYSCTL_XTAL_16MHZ);

    SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C0);
    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);

    GPIOPinConfigure(GPIO_PB2_I2C0SCL);
    GPIOPinConfigure(GPIO_PB3_I2C0SDA);

   
    GPIODirModeSet(GPIO_PORTB_BASE, GPIO_PIN_2 | GPIO_PIN_3, GPIO_DIR_MODE_HW);
    GPIOPadConfigSet(GPIO_PORTB_BASE, GPIO_PIN_2 | GPIO_PIN_3, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_OD_WPU);

  
    I2CMasterInitExpClk(I2C0_MASTER_BASE, SysCtlClockGet(), false);

    I2CMasterSlaveAddrSet(I2C0_MASTER_BASE, SLAVE_ADDRESS, false);


     I2CMasterDataPut(I2C0_MASTER_BASE,reg);
     I2CMasterControl(I2C0_MASTER_BASE, I2C_MASTER_CMD_SINGLE_SEND);

     while(1)
     {}


}



  • TI__Mastermind 26900 points

    There are a couple of things here that I see which are likely to cause you problems. On an LM4F device, despite the fact that I2C uses open drain pins, the open drain behavior of the SCL line is controlled within the peripheral itself and not at the GPIO level. As a result, you need to configure the SCL pin as a standard pin without the open drain property. The SDA pin is still configured as an open drain pin, though. This is confusing but, although the information is in the datasheet, it's not at all obvious - apologies!

    We typically use the following calls to configure the pins on an LM4F232 board:

        ROM_GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);
        ROM_GPIOPinTypePWM(GPIO_PORTB_BASE, GPIO_PIN_2);

    The other thing that you are missing is a call to I2CMasterEnable(). I suspect that adding this before the I2CMasterInitExpClk() would help.

  • in reply to Dave Wilson
    Guru 117855 points

    Dave Wilson said:
    call to I2CMasterEnable().

    In the past - shared this belief with you.  However - for past 60 days or so - we've run multiple I2C Ports w/out using I2CMasterEnable().  I've just triple-checked!  (this on new M4F - should that matter)

    Here's what explains (or confounds): quoting from pg 199, SW-DRL-UG-8555 (current, I believe)

    "When using this API to drive the I2C master module, the user must first initialize the I2C master module with a call to

    I2CMasterInitExpClk()      This function sets the bus speed and enables the master module."  So - perhaps functionality of above has been integrated w/in I2CMasterInitExpClk() - which would be welcome.  (simplification - less to remember/execute)

    Should state further - that I2C code example w/in SW-DRL-UG-8555 makes NO mention of I2CMasterEnable() - yet launches w/ I2CMasterInitExpClk(). 

    Agree - per usual - with all else you've posted.  Perhaps you can investigate this seeming curiosity - again we seem to run/sustain I2C fine w/out I2CMasterEnable().

  • in reply to cb1_mobile
    TI__Mastermind 26900 points

    I guess I should spend some time reading our documentation! Thanks for this correction - I live and learn.

  • in reply to Dave Wilson
    Guru 117855 points

    Not at all a correction - you are endlessly helping/serving others.  We bumped against this 2 months ago - wondered if that function was needed - and simply passed our findings along...

  • in reply to Dave Wilson
    Intellectual 570 points

    Dave Wilson said:
        ROM_GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);
        ROM_GPIOPinTypePWM(GPIO_PORTB_BASE, GPIO_PIN_2);

    I wish you had updated the examples 1 year ago. Would have saved me quite some time.

    Changing the initialization as mentioned by Dave above solved my problem of the TM4C123... hanging in the "while(I2CMasterBusy(I2C0_BASE))"-loop forever, on a EK-TM4C123GXL LaunchPad.

  • in reply to Janos
    TI__Mastermind 26900 points

    Janos,

      Looking at the latest TivaWare, it seems that we made the required modifications already. SInce I posted my original suggestion, we added GPIOPinTypeI2CSCL() which should be used instead of GPIOPinTypePWM() to configure any pin onto which you are muxing an I2C SCL signal. I've grepped the source tree and don't see any example that contains incorrect code. Could you let me know where you see the problem so that I can correct it? Thanks.

  • in reply to Dave Wilson
    Intellectual 570 points

    Hi Dave,

    oh yes, good to see that! I was still working with the 2.0.1 library, but i see the calls fixed in "\examples\peripherals\i2c\master_slave_loopback.c" and also "same\slave_receive.c".

    Thanks for the hint!

    Cheers

    Janos