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 Pin compatibility Problem

Hello!

I am using a DS3231 module with TM4C123GXL. It works perfectly on its own. In particular, I use pins PD0, PD1 with SCL3.

However, I also use EB-LM4F120-L35 LCD touch screen. According to the user manual, PD0 & PD1 has no connection, so I assume these two devices are compatible. However they are not. I try to debug and found out that pin B6 & B7 is interfering the process. Specifically, the problem shows as below;

read_time_from_RTC(); //works perfectly and returns good value.

GPIOPinTypeGPIOOutput(0x40005000, GPIO_PIN_6); //pin B6

read_time_from_RTC(); //can get through but returns bad value;

GPIOPinTypeGPIOOutput(0x40005000, GPIO_PIN_7); //pin B7

read_time_from_RTC(); //get stuck and won't return value.

The code stuck after "flag 5" and entering the loop: while(I2CMasterBusy(I2C3_MASTER_BASE)) {} //this line

detailed code is shown below. I2CMasterBusy() is also given for a direct reference.

void I2C_byte(unsigned char slave_address, unsigned char data) {

volatile int i = 0;

// start I2C transmit
I2CMasterSlaveAddrSet(I2C3_MASTER_BASE, slave_address, false);
I2CMasterDataPut(I2C3_MASTER_BASE, data);
UARTprintf("flag 3 ");
while(I2CMasterBusy(I2C3_MASTER_BASE)) {}
UARTprintf("flag 4 ");
// Single Byte
I2CMasterControl(I2C3_MASTER_BASE, I2C_MASTER_CMD_SINGLE_SEND);
UARTprintf("flag 5 ");
while(I2CMasterBusy(I2C3_MASTER_BASE)) {} //this line
UARTprintf("Success! \n");
}

tBoolean
I2CMasterBusy(unsigned long ulBase)
{
//
// Check the arguments.
//
ASSERT(I2CMasterBaseValid(ulBase));

//
// Return the busy status.
//
if(HWREG(ulBase + I2C_O_MCS) & I2C_MCS_BUSY)
{
return(true);
}
else
{
return(false);
}
}

Could anyone tell why this happens? Thank you very much!

  • On the TM4C123 LPads pins PD0 & PD1 are "tied" to Port B pins (6 & 7) - on purpose!  (this to accommodate an older, lesser MCU - we are advised)   We suspect that this same issue lands upon your older LX4F board. (i.e. you must check board and/or schematic - my sense is that your (more involved, "EB-LX4F" indeed continues that "helpful" MCU to MCU pin, direct (always unwanted) connection.)

    Two 0Ω resistors perform this travesty - friend Roberto voted for their removal - and "tomb-stoning" (stand them up vertically - soldered only to one resistor trace - to remind you of vendor's "care.")

    Many have long protested this (most unfortunate) practice - vendor, even when advised - "knows best" - will NOT budge.

  • I have solved the problem using the following code

    SysCtlPeripheralReset(0x20000002); //SYSCTL_PERIPH_GOIOB //first reset the setting
    SysCtlPeripheralPowerOff(0x20000002);
    SysCtlPeripheralDisable(0x20000002);

    set_time(1,2,3); //set the time, using D0 and D1 pins.
    //I can run read operation as well.

    SysCtlPeripheralEnable(0x20000002); //restart Port B after done with RTC
    SysCtlPeripheralPowerOn(0x20000002);
    GPIOPinTypeGPIOOutput(0x40005000, 0xFF);
    GPIOPinWrite(GPIO_PORTB_BASE, 0xFF, 0x00); //reprogram settings and everything works fine afterward.
  • Good for you - and great detective work to "restore" Port B after RTC altered its settings.

    Please do "Ohm out" PB6 & 7 - to insure that they are not "directly connected" to PD0/1. My firm has that board - but haven't used in years.
  • Somehow I cannot (now) edit post above. I am concerned that your "fix" may have (replaced) one problem with another.   I am very much against the endless re-purposing of Port pins - to "massage out" different behaviors - as dictated by remote devices.

    The fact that this vendor felt forced to configure Port B in one manner - which you then over-ride - strongly suggests that your "fix" will disturb and/or void the vendor's original, code attempt - does it not?   If that's so - you must ALWAYS re-purpose prior to targeting another, bus-connected, device...

    You've set each/every Port B pin as output - and then ordered them (en mass) to 0. In this manner - should they be "cross-connected" those constant LOW pins may well "contend" with a "cross-connectee" which attempts to output logic HIGH. That's never good - you must insure that does not happen. Setting such (currently unused) pins as inputs (instead of outputs) proves far safer.

  • Dear cb1_mobile,

    Thank you so much for the advise. The reason I set all the pins as outputs is that it is required action for LCD touch screen. My debug progress was to track down the code line by line and try running set_time(1,2,3) to see after which line it stops working. That's how I found port B, specifically B6 & B7 are interfering with D0, D1. So I wrote down how it was configured before I disable it. Then I restore the setting as how it originally supposed to be, i.e.(outputs). Is there any better way to do this? Thank you!

    Yucheng
  • And how to "Ohm out PB6 & 7"? I am not sure how to do that. Is that a way to change the "tied" status of PD0/1 with PB 6&7? Thank you!
  • Also, what do you mean by "vendor"? The RTC module's code? Or LCD screen's code? If it is LCD screen, it clearly said that D0, D1 has no connection, which I think it is safe to use.
  • Meant was, "use an ohm-meter to measure the resistance between MCU's PD0 to PB6, and also PD1 to PB7."    

    A board schematic should exist - and briefly/sparingly (i.e. w/out proper emphasis) should detail those (unique) cross connects.    Should those pins be "cross connected" and the "right" combination of GPIO settings occur - your "irreplaceable: LX4F MCU may (most surely will) be harmed!