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.

I2C0 Does Not Transmit Correct Data

Other Parts Discussed in Thread: TM4C129ENCPDT

I am developing with the TM4C129ENCPDT and using I2C0 to interface with a bq27421.  I have it set up to run at 100kHz off of the system clock.  When I try to transmit 3 bytes (0x00, 0x01 and 0x00), on my scope I get the address (0x55) with the write bit, which is ACK'd by the slave, and sometimes a 0x00 and other times a 0x01 followed by what appears to be a clock stretch and another ACK by the slave and then a STOP.  I never have seen 3 data bytes on the scope and the first data byte is usually not correct.

I have the following code for initialization.

I2C0_Init(void {

	SysCtlPeripheralEnable(SYSCTL_PERIPH_I2C0);     //Enable I2C0 peripheral.
	SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);    //Enable GPIO port B so we can use PortB[3:2] for I2C0.

	GPIOPinConfigure(GPIO_PB2_I2C0SCL);             //Configure the pin muxing for I2C0 functions on port B2 and B3.
	GPIOPinConfigure(GPIO_PB3_I2C0SDA);

	GPIOPinTypeI2CSCL(GPIO_PORTB_BASE, GPIO_PIN_2); //Configure B2 for SCL.
	GPIOPinTypeI2C(GPIO_PORTB_BASE, GPIO_PIN_3);    //Configure B3 for SDA.

	I2CMasterInitExpClk(I2C0_BASE, halSys_getClock(), false);
}

And to transmit, the following code.

void I2C0_Write(void {

	I2CMasterSlaveAddrSet(I2C0_BASE, 0x55, I2C_WRITE);

	I2CMasterDataPut(I2C0_BASE, 0x00);
	I2CMasterControl(I2C0_BASE, I2C_MASTER_CMD_BURST_SEND_START);
	while (I2CMasterBusy(I2C0_BASE) == true);

	I2CMasterDataPut(I2C0_BASE, 0x01);
	I2CMasterControl(I2C0_BASE, I2C_MASTER_CMD_BURST_SEND_CONT);
	while (I2CMasterBusy(I2C0_BASE) == true);

	I2CMasterDataPut(I2C0_BASE, 0x00);
	I2CMasterControl(I2C0_BASE, I2C_MASTER_CMD_BURST_SEND_FINISH);
	while (I2CMasterBusy(I2C0_BASE) == true);
}

The scope shot below has SDA on the top and SCL on the bottom.  As you can see, the address is transmitted correctly, but the first data byte that is transmitted is 0x01 (it should be 0x00).  The second byte transmitted is 0x00, but it should be 0x01.

Thanks,

Jim

  • Hello Jim,

    Can you add a delay before each of the statements and check?

    SysCtlDelay(1000);
    while (I2CMasterBusy(I2C0_BASE) == true);

    Regards
    Amit
  • Hi Amit,

    Yes, this resolved the issue, but why is any delay required?

    Also, setting the data rate to 400kbps resolved the issue without requiring any delays.

    Regards,

    Jim

  • Hello Jim,

    The issue is the Write of a command to the I2CMCR register and the readback of Busy Status when the clock difference between the System Clock and I2C SCL is high. As a result it is some time after the Internal state machine starts that the Busy Flag gets set. If the CPU does a read before the State machine reaches this state the function will read back a 0 causing it to move to the next command and thus resulting in the given scenario.

    Regards
    Amit
  • Hi Amit,

    Thank you for the detailed response. Is there any other way around this than to insert a delay? Would polling for one of the Raw Interrupt Status bits in I2CMRIS allow for a shorter delay before reading the BUSY bit in the I2CMCS register? If so, which bit(s)?

    Thanks,
    Jim

    P.S. Would using an interrupt-based I2C handler also resolve this?
  • Hello Jim,

    Ideally the interrupt mechanism is the method to use. The Bit-0 (marked RIS) is the interrupt bit that shall indicate the status of Master Transaction Complete.

    Regards
    Amit
  • Hi Amit,

    This seems like it is something that should be noted in the datasheet for this and any other affected microcontrollers.

    Regards,
    Jim
  • Hello Jim,

    I understand and we have had a recommendation for the same. However, it is being debated as a bug or a note...

    Regards
    Amit
  • Proper & timely alerting of your user/clients should not be held hostage to an internal debate!

    Allowing "known issues" to persist - without proper warning - is not noted for boosting sales. (nor showing care/concern for valued clients...)
  • Agreed, there's already a way to go around this problem. Everyone take the examples as a base (or most do) so if there's a problem with the method then it should be easy for them to find. Don't you agree?

    I'm still curious about the source of this behavior since it seems to not be present on slower devices (shouldn't the I2C module have the same clock?), but I guess that's more curiosity than anything else.
  • Hello Luis, cb1,

    I can push for a recommendation not have the final verdict. Having said that this has been a top list item (amongst others), that I have asked forum users/customers to check. But search seldom is performed

    Regards
    Amit
  • Amit Ashara said:
    I have asked forum users/customers to check. But search seldom is performed

    That's one approach - but does it not force extra effort upon each/every user/client?   And how do they know where & when & how to search?

    Do not "strong & proper guard rails" exist along most highways - when a deep "fall-off" parallels the road?  

    Known errors should not be "resolved" by forcing each/every user-client to perform a forum search - sad if that's the best your group can suggest...

    Burying, hiding, obscuring "well & long known" errors is a very poor substitute for their correction - or proper (i.e. emphasized) presentation - to alert the unwary!

  • Amit,

    Is there another post that details this same issue? If so, where? I searched for my issue, but did not find any posts with the same problem.

    Jim
  • Hello Jim

    Either using delay or by using the "!" condition for command to begin

    e2e.ti.com/.../1146647

    Regards
    Amit
  • Amit,

    I did not find that post when doing my search. In addition, your answer to that post does not give any insight into what was actually happening. The details in this thread are of much greater benefit.

    Regards,
    Jim
  • Hello Jim,

    There have been previous post where I have explained the same. (I used the search key I2CMasterBusy). But it seems that I will have to use this thread for future references.

    Regards
    Amit
  • Hi Amit,

    Unfortunately, I did not know that the problem had anything to do with I2CMasterBusy, so I was not searching for it. I was just searching for what I was observing, which was ultimately the title of my post. It seems that posting with a title related to what issue you are observing is the most useful.

    Regards,
    Jim
  • Hello Jim,

    I think I can add it to the Diagnostic Post.

    Regards
    Amit
  • Jim Gavin said:
    Unfortunately, I did not know that the problem had anything to do with I2CMasterBusy, so I was not searching for it.

    Hi Amit,

    Jim's writing (above) is classic - experts (i.e. you) have total awareness - but mere mortals (Jim, cb1, others) often struggle to "make connections" which seem so obvious/basic to you!   And you are not alone in that type situation - it is surprisingly common.

    Is not - first the recognition - then the search - for one of "hundreds" of MCU parameters - expecting a bit much from your client-users?   (Ans: mais certainement!)

    I don't see a good answer as anything but a well-thought & constructed, "flow chart guided" detailed narrative - dedicated to individual peripherals, and placed in an easily reachable - well publicized space.   (btw - where are the TM4C App Notes now?    How would your client-users know (and find) these?)

    Present "search Forum & (maybe) find" may (sometimes) work - yet is too much like, "needle in a haystack!"   (apologies to the haystack...)

    Clearly the "Forum Search" proves "better than nothing" - but is a poor substitute for properly detailed - high effort - MCU Peripheral-focused App Notes - long promised - and (perhaps) lost in the rush to, "booster packs!"   (my opinion)

    Again - as always - no one blames you - our wish is for the better husbanding of your vital resource - so that the best good lands on this community...

  • Once again, I can fully second cb1's post.

    I cannot fathom how some higher level managers at TI apparently think it's OK to just try to manage all the problems by putting out fires all around town instead of shutting the central gas valve...

    Let me share my personal "rant list" - parts of which I'm sure others can embrace, too. Amit, please take off your TI hat when reading this - I classify you as one of 'us', I believe you carry a much bigger burden because of these problems than the average forum user. 

    1. TivaWare has outstanding bugs that apparently have been fixed "in-house", some over a year ago already. These include, but in no way are limited to, for example the erroneus output of SysCtlClockGet at 80 MHz, and given that SysCtlClockGet is used as a clock input to multiple peripheral initialization functions in the examples, I would classify this as top priority. The kind of which I would expect to be fixed in a release within a month of reporting the bug. Now, what everyone might not know is that the release of a new TivaWare is being held hostage by the IoT example code of the '129 launchpad. Let me rephrase: because the out-of-box example on the '129 launchpad does not work for more than a week at a time, every single user of the whole TM4C line has to suffer undocumented bugs that can really cause you to scratch your head! This is in my opinion a colossal failure in version control, and is something TI has to work on in the future if they wish to retain a professional appearance.
    2. The influx of ignorant newbies on this forum proves there is a lack of 'starting guidance' for the LaunchPads (that's where most of them are coming from, I'd bet - heck, that's why I'm here! But I was patient enough to watch all the tutorial videos before even starting up CCS...). I checked the ti.com/launchpad site just now and while there is a lot of good information presented in a beginner-friendly way, I think a firm "START HERE" -type of section with clearly laid out "homework" would benefit everyone. Don't get me wrong, there's nothing wrong with being a newbie - but it's no benefit to the community if we just get a vomit of code accompanied with "doesn't work!". What is needed is a gentle but firm way - TI sanctioned -  to tell these people to go do their homework before they post. Cb1, If I'm not mistaken, you've tried to speak up about this for a long long time (you even have a solution "ready to go", don't you?), and frankly I wonder how you still have the energy to do so, after being practically ignored all this time. For the record, you have my utmost respect for keeping it up.
    3. There are some nasty "gotchas" in the errata for the TM4C processors (not that it's in any way a unique trait to the TM4C nor TI, it's global) - yet the datasheets for the respective devices completely fail to highlight these issues. It's like the datasheet is a document of how the devices are supposed to work, and then a with combination of combing through errata and driverlib source code you might arrive at how the devices actually work. We're in 2015 and the datasheets look like they are digitally generated (or TI has the best printers & scanners in the world!) - changing them and releasing new versions, even with really minor changes - just to note that the one bit in that one registry doesn't actually do what was intended - should not be a technical issue! At the very minimum there should be a "NOTICE! This function is affected by errata on certain silicon revisions" kind of side note in the datasheet. Checking multiple "authoritative" documents is so 80's!
    4. The same goes for the "gold nuggets" stored somewhere deep within the forum - there needs to be a way to collect all of the tips & tricks to a central location - I think it's been proven on multiple occasions that the search just doesn't quite cut it. Cb1 already had many points on this in his above message that I'm not going to repeat here.

    Rant over.

    -Veikko

  • Veikko Immonen said:
    putting out fires all around town instead of shutting the central gas valve...

    Among the "all-time" spectacularly memorable - and colorful - encapsulations of what I've been (among others) trying to correct or at least reduce!   Superb word play Veikko!    Clearly - convincingly - illustrates the hugely flawed, "serial bandaid approach" - too long in play...

    Indeed the decisions (from above) seem not based in real experience - nor reality - and fail the client-users badly.   And repeatedly.    And continue.   And continue.    And continue.   (did I say that?)   

    "Duly noted" (standard vendor response) is unacceptable when (so many) drive off the failed,  still unmarked, vehicle disgorging, canyon road...

    This reporter makes no claim to perfection - but (some) common sense dictates that "known MCU design or usage flaws" do little good - when, "Buried, hidden, or (may I ask) willfully withheld!"    And sadly - such appears (almost) as a "sense of pride" to those in master-control - here!   

    Why is that?   Who benefits?    Really?