I2C master-slave loopback works, but no signals on pin

Hello Dennis,

Yes, you would need external pull up to see the master communication. Also do make sure the I2C Pins are configured correctly. You can refer to the sensor hub code for configuration of the I2C Pins.

Regards
Amit

Thanks, Amit.

What are the recommended values of the pull-up resistors? Do we need to connect a pull up to both SDA and SCL?

What is the "sensor hub code"? My I2C configuration comes from the master_slave_loopback.c example that comes with TivaWare_C_Series-2.1.0.12573, and at least according to the UART output of the program, everything works smoothly.

I also tried using I2C configurations generated by the PinMux utility. I think the settings are equivalent. They produce the same result.

Hello Dennis

The value of the pull up is decided by the application requirement on speed, number of devices, traces and current leakage. We have 3.3K on the Sensor Hub booster pack and it can be relaxed till 4.7K.

Can you share the Configuration code?

Regards
Amit

We are working without a booster pack. We're running the loopback and expecting to observe electric signals on the wire. Currently, a 3.3K resistor pulls both SDA (I2C0, PB3) and SCL (I2C0, PB2) up. What we observe is a high state on both pins at reset, and a constant low state afterwards, even as we see all the correct UART prints of the code.

Here's the configuration code, straight out of PinMux:
//
// Enable Peripheral Clocks
//
MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C0);
MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);

//
// Enable pin PB3 for I2C0 I2C0SDA
//
MAP_GPIOPinConfigure(GPIO_PB3_I2C0SDA);
MAP_GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);

//
// Enable pin PB2 for I2C0 I2C0SCL
//
MAP_GPIOPinConfigure(GPIO_PB2_I2C0SCL);
MAP_GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_2);

As for what these macros resolve to, I am defining the symbol TARGET_IS_TM4C129_RA1

Hello Dennis,

The define is correct and may be you have added PART_TM4C1294NCPDT as well (this is used by the pin_map.h for the pin map macro).

As for running the internal loopback and signal viewing on the IO, I don't think that is possible (never tried to be honest);

Regards
Amit

Dennis Begun said:

Currently, a 3.3K resistor pulls both SDA (I2C0, PB3) and SCL (I2C0, PB2) up.

To clarify - you are using two such 3K3 pull-up R's (one to SDA and one to SCL) are you not?  (writing suggest only a "single" R!)

Perhaps there's something (unwanted) sitting upon those pins?   Quick/dirty test (our favorite) has you (temporarily) re-purposing those 2 pins from I2C into GPIO Outputs - and toggling each.  (this establishes that the pins can output - and are not otherwise loaded)

You, "expect to observe electric signals on the wire."   Should not that be on, "both wires?"   And - by what means do you attempt that observation?  Realize that I2C transfers usually are brief - signals are fleeting - and then the lines are quiet - with both returning "high" if all is well.

Yes, 2 different resistors pull each of the lines up.

I've tested the pins as GPIO, they work as expected.

I've seen I2C on a scope before, I'll know 'em signals when I see 'em. I'm definitely not seeing 'em :). I'm on a 500MHz scope, trying to observe 100kbps signals, surely they'd show up.

A question that's fairly central to my investigation is whether the loopback code is supposed to produce signals on the pins of the eval board. Maybe the loopback isn't supposed to make it out to the pins at all. I'm using the loopback code as a starter for code that writes/reads to an external device, maybe I'm doing something wrong in the process.

Hello Dennis

As I indicated earlier, the loopback code may not produce results on the IO's. You must exit the loopback mode.

Regards
Amit

Thank you, Amit and cb1.

I am now beginning to see signals. At least one of the problems was an improper I2C clock configuration.

Hello Dennis

Did you use the SysCtlClockGet for the system clock parameter?

Regards
Amit

Right now I'm using the return value of SysCtlClockFreqSet, and it seems to work.

Right now I removed the loopback mode, and trying to place a few bytes on the wire. I can't see the bytes, but I do see the slave address byte, which makes sense. I have nothing ACKing on that line yet, so the code hangs on

while(!(I2CSlaveStatus(I2C0_BASE) & I2C_SLAVE_ACT_RREQ))
{
}

No bytes are sent even if I cancel this loop, by the way.

Hello Dennis,

I believe the slave is the on-chip slave and not an external device. Do make sure that the I2CSOAR is programmed with the same value as the I2CMSA

Regards
Amit

Hello Dennis,

I found the following text in the datasheet in I2C chapter Section 3.4 "Loopback Operation".

In loopback mode, the SDA and SCL signals from the master and slave are tied to the SDA
and SCL signals of the slave module to allow internal testing of the device without
having to go through I/O.

The last part of the above statement says "without having to go through I/O". So looks like the data does not reach the I/Os.

Thanks,

Sai

My hat is off. Thanks, that settles that part.

In my case, when I am not planning on using the Tiva as a slave, why would I2CSOAR be relevant?

Stellaris Sai said:

allow internal testing of the device without having to go through I/O.

Mes Amis,

Are we all not "missing" the obvious.  To escape the "hedge" of, "signals may not appear" - simply "remove" any/all EXTERNAL, physical-wire loopback connections - which have been added to implement a "real" physical loopback.  Should this loopback work - the loopback is realized via internal MCU routings.

That said - it does not (by itself) provide hard evidence that the I2C signals are not directed to the MCU's pins.  (although - coming from a similar semi-firm - I'd suspect that a data selector "steers" the signals away from MCU pins to the targeted I2C peripheral - internally.  It is this "internal steering" of I2C signals away from MCU pins (clearly inadequately described) - which the poster may have exposed...

Perhaps the depth and justification of vendor's design execution - as detailed herein (by outsider) - warrants a 2nd, "hat tip?"  (Verify Answer even better)