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.

Alternate I2C pins on CC3200 not working.

Other Parts Discussed in Thread: CC3200

Hi,

I need to use the alternative pins of the I2C namely pins 3 and 4.I have done the changes in the pinmuxconfig.c file according to the file generated by TI PINMUX utility. Yet i am not able to use them. On the normal default pins (1 and 2) the I2C communication works fine.

Please tell me if there is any other initialization sequence required.

Also I have gone through this post which is the same problem I am having and none seems to work fine().

Regards

John 

  • Hi,

    I can confirm that advices to change MUX pins PIN_01, PIN_02 to GPIO works well if you want change I2C to PIN_03 and PIN_04. I think you have hardware issue - like missing pull-up on I2 bus or switched SDA and SCL.

    Jan

  • Hi Jan,

    I am using pull-ups of 10k on each of the lines.

    Switched SDA and SCL,what do you mean by that?

    Also can I ask did you just change the pinmuxconfig.c file or is there any more changes to be done in the code?

    Regards
    John
  • Hi,

    I mean just exchanged SDA and SCL.

    But if you have only 10k pull-pus that is issue because P04 is also connected to SW3 with pull-down 10kB if I am not wrong. Please see schematic for launchpad. Just press switch SW3 or add there much stronger pull-up.

    Jan
  • Hi,

    Thanks for the reply.

    I have tested the code on another custom board with 3k pull-ups .Yet the problem still persists.

    Having any suggestions?

    Regards
    John
  • Hi,

    I am slightly confused. Are you using own hardware with CC3200 or LaunchPad? If LaunchPad I think you have still problem with voltage level on SDA line (PIN4 - GPO13). You can check voltage level by oscilloscope. And you will see there about 2.5V [3.3*(10000/(3000+10000)=2.54V]. I think this voltage level is not sufficient for you I2C hardware.

    If you use 1k pull-up on PIN04 or press button SW3 or remove resistor R117 from LaunchPad it fix your problem.

    Jan

  • Hi,

    Actually I also have the launchpad as well as a custom board.I have cross verified the program on both the hardware.

    But still I will confirm after some testing of hardware.

    I wanted to know if only the pinmux changes are to be made and nothing else more in the code?

    Thanks
    Regards
    John
  • here is a handy primer on this topic (how to choose your pull up resistor, based on your system)
    www.ti.com/.../slva689.pdf
  • Hi,

    I have very complex project and from this reason I not use standard file generated by Pinmux utility. But this is not important. Pinmux utility don't do nothing mysterious. Just only set PinMux peripheral. If you use code generated by Pinmux utility which change PINs for I2C and add code which set PIN_01 and PIN_02 to GPIO, it will work. Of Course you can have something else wrong. I think best start it to use osciloskop and check SDA and SCL lines.

    Jan
  • Hi,

    No, setting the Pins 1 and 2 to GPIO also did not solve the problem.

    John

  • Hi,

    You can share your pinmux code and we will see if is correct. But I think without checking of physical state of I2C pins on oscilloscope you will not move forward.

    Jan
  • Hi,

    Here is my pinmux code.

    MAP_PRCMPeripheralClkEnable(PRCM_GPIOA0, PRCM_RUN_MODE_CLK);
    MAP_PRCMPeripheralClkEnable(PRCM_GPIOA1, PRCM_RUN_MODE_CLK);
    MAP_PRCMPeripheralClkEnable(PRCM_GPIOA2, PRCM_RUN_MODE_CLK);
    MAP_PRCMPeripheralClkEnable(PRCM_I2CA0, PRCM_RUN_MODE_CLK);


    MAP_PinModeSet(PIN_01,PIN_MODE_0);
    MAP_PinModeSet(PIN_02,PIN_MODE_0);

    //
    // Configure PIN_03 for I2C0 I2C_SCL
    //
    MAP_PinTypeI2C(PIN_03, PIN_MODE_5);

    //
    // Configure PIN_04 for I2C0 I2C_SDA
    //
    MAP_PinTypeI2C(PIN_04, PIN_MODE_5);


    //
    // Configure PIN_64 for GPIO Output
    //
    MAP_PinTypeGPIO(PIN_64, PIN_MODE_0, false);
    MAP_GPIODirModeSet(GPIOA1_BASE, 0x2, GPIO_DIR_MODE_OUT);

    //
    // Configure PIN_15 for GPIO Input
    //
    MAP_PinTypeGPIO(PIN_15, PIN_MODE_0, false);
    MAP_GPIODirModeSet(GPIOA2_BASE, 0x40, GPIO_DIR_MODE_IN);

    Regards
    John
  • Hi,

    Try use this:

    MAP_PinTypeGPIO(PIN_01, PIN_MODE_0, false);
    MAP_GPIODirModeSet(GPIOA1_BASE, 0x4, GPIO_DIR_MODE_OUT);
    MAP_PinTypeGPIO(PIN_02, PIN_MODE_0, false);
    MAP_GPIODirModeSet(GPIOA1_BASE, 0x8, GPIO_DIR_MODE_OUT);
    

    instead

    MAP_PinModeSet(PIN_01,PIN_MODE_0);
    MAP_PinModeSet(PIN_02,PIN_MODE_0);

    Jan

  • Hi Jan,

    Apology for the late reply.

    As suggested by you, we have tested the same configuration on our custom board, but it didnt work. I2C bus faults were still coming.We thought of testing the launchpad once with the same configuration (Pins 3 and 4 configured as SDA & SCL). For this, we have isolated the resistors (R116 & R117) so that switch (SW3) will be completely isolated from the GPIO. Also, we have provided external pull up resistors to these pins which are pulled up to 3.3V.

    After verifying the hardware connections of launchpad, we tested the same code and found that I2C is not working and we are getting the same bus faults as earlier.
    We measured the I2C lines voltages as well, and both were 3.3V.

    We are in big trouble since CC3200 pins 3 and 4 are not working.

    Can you please check this at your end by isolating the resistors (R116 and R117) on the launchpad? Let us know your observations.

    Also, do you think we have missed out anything in our basic configuration ?

    Waiting for your reply.

    Thanks
    John

  • Hi,

    I think you have something else wrong inside your code. We use I2C at pin 3 and 4 without any issue. In our code we have I2C at 1 MHz. According our observations is I2C peripheral in CC3200 reliable. Only thing which we not able get to work is FIFO buffer for I2C receive. Because it need some testing, we left the FIFO buffers in I2C for later stage.

    Did you check the SDA and SCL lines at oscilloscope? Do you see there any activity?

    This is my I2C init code. It configure I2C and interrupts for IC:

    // Config structure for SW or HW I2C
    //
    typedef struct {
      // GPIO port for SDA (GPIOA0_BASE, GPIOA1_BASE, GPIOA2_BASE, GPIOA3_BASE)
      unsigned long                    portSDA;
      // pinu number at CC3200 IC for SDA (PIN_02, PIN_04, PIN_06, PIN_17)
      unsigned long                    pinSDA;
      // GPIO mask for SDA
      unsigned char                    maskSDA;
      // GPIO port for SCL (GPIOA0_BASE, GPIOA1_BASE, GPIOA2_BASE, GPIOA3_BASE)
      unsigned long                    portSCL;
      // pinu number at CC3200 IC for SCL (PIN_01, PIN_03, PIN_05, PIN_16)
      unsigned long                    pinSCL;
      // GPIO mask for SCL
      unsigned char                    maskSCL;
      // I2C frequency
      long                             speedI2C;
    } I2Ccfg_t;
    
    
    // Get pinmux mode from pin number
    //
    static unsigned long I2CgetPinMuxMode(unsigned long pin) {
      switch(pin) {
        // I2C at PIN_01 a PIN_02
        case PIN_01:
        case PIN_02:
          return PIN_MODE_1;
        // I2C at PIN_16 a PIN_17
        case PIN_16:
        case PIN_17:
          return PIN_MODE_9;
      }
      // PIN_03, PIN_04, PIN_05 a PIN_06
      return PIN_MODE_5;
    }
    
    
    // Open I2C hardware
    //
    void I2COpenHW(I2Ccfg_t *cfg) {
    
      int i;
    
      #define I2C_O_MTPR          0x0000000C
    
      // save config structure
      hwI2Ccfg = cfg;
    
      // generating pulse at SCL line for "unfreeze" slaves
      MAP_PinTypeGPIO(cfg->pinSCL, PIN_MODE_0, false);
      MAP_GPIODirModeSet(cfg->portSCL, cfg->maskSCL, GPIO_DIR_MODE_OUT);
      MAP_GPIOPinWrite(cfg->portSCL, cfg->maskSCL, 0xFF);
      for (i = 0; i < 2; i++) {
        MAP_UtilsDelay(120);
        MAP_GPIOPinWrite(cfg->portSCL, cfg->maskSCL, 0x00);
        MAP_UtilsDelay(120);
        MAP_GPIOPinWrite(cfg->portSCL, cfg->maskSCL, 0xFF);
      }
    
      // enable clock for I2C peripheral
      MAP_PRCMPeripheralClkEnable(PRCM_I2CA0, PRCM_RUN_MODE_CLK);
      // switch pinmux for SCL a SDA lines
      MAP_PinTypeI2C(cfg->pinSCL, I2CgetPinMuxMode(cfg->pinSCL));
      MAP_PinTypeI2C(cfg->pinSDA, I2CgetPinMuxMode(cfg->pinSDA));
    
      // reset
      MAP_PRCMPeripheralReset(PRCM_I2CA0);
    
      // set frequency
      if (cfg->speedI2C == I2C1MHZ) {
        // 1MHz
        MAP_I2CMasterEnable(I2CA0_BASE);
        HWREG(I2CA0_BASE + I2C_O_MTPR) = 2;
      } else {
        // 100kHz, 400kHz
        MAP_I2CMasterInitExpClk(I2CA0_BASE, 80000000, cfg->speedI2C);
      }
      // clear all interrupts from I2C
      MAP_I2CMasterIntClearEx(I2CA0_BASE, 0xFFF);
      // set irq sources
      MAP_I2CMasterIntEnableEx(I2CA0_BASE, I2C_MASTER_INT_DATA |
                               I2C_MASTER_INT_TIMEOUT);
      // enable I2C master block
      MAP_I2CMasterEnable(I2CA0_BASE);
    
      // set I2C state byte to idle
      gI2CStateHW = I2C_IDLE_HW;
    }
    

    Jan

  • Hi Jan

    Thanks for the reply. My code is working fine on Pins 1 and 2 as well as 5 and 6. I cannot tell if there is a problem with the default driver implementation.As I can understand you have created a custom driver file for yourself.

    I will try testing out with this code.

    Thanks

    Regards

    John

  • Hi Jan

    I have to clarify. It seems that you have written the code without the use of TI-RTOS. As I am TI-RTOS there is no need for me to implement all this code as it is done by the OS itself.

    I wonder if there is a problem with the RTOS driver implementation for pins 3 and 4 for I2C.Could you suggest me anything if possible.

    Regards
    John
  • Hi,

    I expect that you are using files i2c_if.c/h. This files are not part of TIRTOS, as I know. This is "abstraction" layer above driver lib. But this is not important. I don't use this code because is not much efficient. As to be honest, in bigger multitasking application where speed is important is this code useless. Even interrupts are not used in this library. This is nothing more than simple example how use I2C at CC3200.

    But I did not expect any problem in i2c_if.c/h, because code is straight forward. I expect that you have something else wrong on your hardware or software.

    Jan
  • Hi Jan,

    Thanks for your reply.

    We are actually not dealing with the firmware level of coding.
    As you can go through the previous posts, we are more concentrated on the RTOS implementation.
    But just to be clear on the hardware side, we have done the firmware coding and found that the pins 3 and 4 are working fine of CC3200 launchpad with the firmware level. It worked straight forward without any issues.
    This tells that those pins are functional and can be used for I2C communication.We are able to conclude that the CC3200 has no issues wrt the I2C communication when it comes to the firmware level.

    With the RTOS drivers implementation we have no problems with I2C communication on pins 5/6 an d 1/2. But we are facing this issue only when pins 3 and 4 are used which makes me suspect the internal implementation of the driver, maybe some configuration is not getting set correctly(not very sure,have to go through the OS internals).

    Can you please check the I2C communication using TI-RTOS with pins 3 and 4 as I2C ?
    I would be great if you can check it at your end so that we can conclude quickly over this issue.
    Looking forward for your response.

    Regards
    John