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.

Help: tm4c1290NCPDT I2C no signal on SDA/ SCL

Other Parts Discussed in Thread: TM4C1290NCPDT, TM4C1231H6PZ

Hi,

I am having a hard time getting signal out of tm4c1290NCPDT I2C. I tried on I2C1 (PG0, PG1) and I2C5 (PB0, PB1).

Using I2C1 on pin PG0 and PG1, 10K pull up to VDD, I am unable to get any signal out of SDA and SCL. The lines under scope stay low all the time.

The same code with different pins and peripheral worked on tm4c1231h6pz. I checked the data sheet, as well as the library user guide, and the errata sheet, and could not find any relevant information.

When trying to configure the pins as GPIO and wiggle them, the waveform is correct.

There is not any device currently connected to the two pins except the pull up resistors.

Is there a document that highlight the subtle differences between tm4c123 and tm4c129 i2c?

Thanks

#defines:

	#define I2C_PERIPH		SYSCTL_PERIPH_I2C1
	#define GPIO_BASE		GPIO_PORTG_BASE
	#define GPIO_PERIPH		SYSCTL_PERIPH_GPIOG
	#define PIN_SCL			GPIO_PG0_I2C1SCL
	#define PIN_SDA			GPIO_PG1_I2C1SDA
	#define I2C_BASE		I2C1_BASE
	#define GPIO_SCL_PIN		GPIO_PIN_0
	#define GPIO_SDA_PIN		GPIO_PIN_1

	#define PEN_GPIO_BASE		GPIO_PORTN_BASE
	#define PEN_GPIO_PERIPH 	SYSCTL_PERIPH_GPION
	#define EN_GPIO_BASE		GPIO_PORTH_BASE
	#define EN_GPIO_PERIPH 	SYSCTL_PERIPH_GPIOH
	#define PEN1_PIN		GPIO_PIN_0
	#define PEN2_PIN		GPIO_PIN_1
	#define PEN3_PIN		GPIO_PIN_2
	#define PEN4_PIN		GPIO_PIN_3
	#define EN_PIN			GPIO_PIN_2

init functions: 

	//enable I2C
	SysCtlPeripheralEnable(I2C_PERIPH);

	//init configuration
	I2CMasterInitExpClk(I2C_BASE, sysClkRate, 0);

//    // Configure the pin muxing for I2C1 functions on port G0 and G1.
    GPIOPinConfigure(SEPIC_PIN_SCL);
    GPIOPinConfigure(SEPIC_PIN_SDA);
//
//	//configure pin for SCL
	GPIOPinTypeI2CSCL(SEPIC_GPIO_BASE, SEPIC_GPIO_SCL_PIN);
//
//	//configure pin for SDA
	GPIOPinTypeI2C(SEPIC_GPIO_BASE, SEPIC_GPIO_SDA_PIN);

	//enable as master
	I2CMasterEnable(I2C_BASE);

send function:

void I2CWriteReg(uint32_t ui32Base, uint8_t ui8SlaveAddr, uint8_t ui8RegCMD,  uint8_t data){


	//set slave address to communicate to: i2c bus base, slave address, receive = false
	I2CMasterSlaveAddrSet(ui32Base,ui8SlaveAddr,false);

	//send command byte to write to WIPER register
	I2CMasterDataPut(ui32Base,ui8RegCMD);

	printf("Cmd to be written to WIPER register 0x%x slave address 0x%x wiper register 0x%x\n", data,ui8SlaveAddr, ui8RegCMD);

	//set master to send
	I2CMasterControl(ui32Base,I2C_MASTER_CMD_BURST_SEND_START);

	//wait for bus to get cleared
//	while(I2CMasterBusy(ui32Base)){};

	//send byte to set wiper to command input
	I2CMasterDataPut(ui32Base,data);

	//end
	I2CMasterControl(ui32Base,I2C_MASTER_CMD_BURST_SEND_FINISH);
	// Delay until transmission completes
//	while(I2CMasterBusy(ui32Base)){};   <<have to comment out because it causes the code to hang waiting for master to get cleared
}

  • Hi,

    Maybe because you forgot to enable clock for PORTG.

    SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOG);  // edited

    Where did you define SEPIC_PIN_SCL, SEPIC_PIN_SDA, SEPIC_GPIO_BASE?

    - kel

  • Hello Kel,

    Isn't this the case for a typical bus fault? Stopping the debugger would have indicated that the code is looping in the FaultISR.

    Regards
    Amit
  • Hi Amit,

    And - further - poster indicated that he (earlier) "wiggled" each pin via their config as GPIO.   Thus - unlikely that so obvious a "set-up" error would have been introduced when changing to I2C...  

    Poster would have had to (deliberately) "kill" the enabling of Port G for Kel's suggestion to make sense - and then of course his program would have faulted - as you note...

  • Hello cb1

    It could be that in the debugger the user set the registers manually and checked the pins and "voila" it worked. But forgot to add the port enable to application code. I have erred at the same place a few times.

    Regards
    Amit
  • Hi Kel,

    Thank you so much for your reply, 

    The port is enabled, other wise the program would crash right at init.

    SEPIC_PIN_SCL, SEPIC_PIN_SDA, SEPIC_GPIO_BASE are actually defined with out the SEPIC_ in front. they are PIN_SCL, PIN_SDA, GPIO_BASE which are defined in the #define included

    -truong

  • Hi Amit,

    Thank you so much for your reply. I did not fiddle with any register calls. All I used to setup and communicate with the port are from tivaware APIs.

    I verified couple times that the port has been enabled, both on the old TM4C123 code and this code, and I am using XDS200 to load the code on the board only, not for any debugging purposes.

    I also tried the code without the port being enabled, and it crashes right away. 


    -truong

  • Hello Truong,

    What do you mean by crashes right away? The full code would be useful for analysis on our side while you can make a simpler code with the bare minimum initializations to see the result.

    Regards
    Amit
  • Hi Amit,

    Without the port enabled, the code will crash at bus fault right when I try to initialize the port.
    What other part of the code do you think would be relevant to post? I would not be able to post the full code.

    -truong
  • Hello Truong

    You mentioned "Using I2C1 on pin PG0 and PG1, 10K pull up to VDD, I am unable to get any signal out of SDA and SCL. The lines under scope stay low all the time."

    1. When you erase the flash and power cycle the board does the PG0 and PG1 remain low or high? If it remains low then the issue is with the Pull Up on your board.
    2. I asked to create a small code of I2C Initialization and GPIO Configuration that can reproduce the issue (if you cannot paste the full code). The code should be compilable (not just code snippets as in the first post)

    Regards
    Amit
  • The problem I found was that of Amit suggested, the pull-ups were not properly added. reworked the pieces and i2c working ok now.
    Thanks Amit
  • Absence of those pull-ups should have been easily & quickly noted. (i.e. both signal lines would not be @ "stiff 3V3")

    We note that you reported, "The lines under scope stay low all the time" thus those pull-ups (all 2 of them!) should have been quick/easy/obvious check!

  • Hi cb1-,

    There are pull up resistors, but the person who populated the board connected it to GND instead of VDD.

    -truong
  • TruongNguyen Trinh said:
    There are pull up resistors

    May I (respectfully) disagree?   Connected in that manner - those were pull-down resistors!   (the absence of voltage upon SCL/SDA lines should have proved a "dead give-away.")

  • It was my fault for assuming the resistors were put in correctly.
    Have you had any experience with using the uC internal weak pull-up? On both the tm4c123 and 129, despite the datasheet says that there is a weak pull up that can be used instead of the external pull up resistors, I always end up using the external one to get correct signal output.

    Thanks cb1-
  • Hello Truong,

    The IO Pull are very weak and may not give sufficient guard against noise. Also based on the I2C Load they may violate the slave device requirement for rise times.

    Regards
    Amit
  • TruongNguyen Trinh said:
    Have you had any experience with using the uC internal weak pull-up?

    Yes we have - and it is most always, "Negative!"   We use many ARM MCUs (multiple vendors) and in most every case the "internal" pull-up resistors prove inadequate.

    This is more a, "Risk-Reward" than engineering question.   Is your "saving" (cost/size penalty imposed by 2, 06-03 resistors) worth a (likely) "less than robust" communication link?   The increased resistance will "round" your signal edges - likely shorten connection distance - and has proven to cause "drop-outs" and/or signal errors.   We thus find any "savings" to not justify the risk...