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.

RTOS/TM4C123GH6PM: Run i2ctmp006_EK example and i2c clock be pulled low when access unknown address

Part Number: TM4C123GH6PM

Tool/software: TI-RTOS

hi Champs,

I ran TM4c123-EK TI-RTOS example code. I write slave address = 0x50 which didn't exist. On I2C bus, it generates address NACK and sent first byte out. in first I2C transfer, TM4C123 issue STOP bit and it looks like generate automatically. However, it didn't issue STOP bit in second transmission. SCL keep low after second transmission finished. Why 123 didn't issue STOP bit if it got address nack ? Why it still sent out 1 byte data. Why 123 didn't issued a STOP bit after second transaction?  

I checked i2cTiva.c. there is a else loop which write

        if (errStatus & (I2C_MASTER_ERR_ARB_LOST | I2C_MASTER_ERR_ADDR_ACK)) { 
           
            I2CTiva_completeTransfer((I2C_Handle) arg);

}

I just wonder that why 123 got address nack and still need to complete transfer ? Could you please tell me why our example write this condition ? thanks!

1. first transaction

2. second transaction

3. whole transaction

  • Hi Lisa,

      I agree that if the master is NACK'ed it should just issue the STOP and terminate according to the transmit flowchart shown below. As you can see the CPU is supposed to write a STOP bit as in "---0-100" to the I2CMCS register when an error occur. However, the flowchart is implemented in software. I think the TI-RTOS may have taken slightly different approach to terminate the transaction when an error occur. I'm not familiar with the intricacy of how TI-RTOS handles the I2C errors. Perhaps it has extra I2C transactions pending and queued up that it must unpend before terminating. We can check with the TI-RTOS expert. 

      

  • hi Charles,
    could you please tell me who is TI-RTOS expert ? base on your comment, it looks like STOP bit is issued by TI-RTOS. Am I right ? thanks
  • Hi Charles,

    I found out when first transaction finished, the I2CMCS status register value is weird. Why bus idle & busy flag exist in same time ? Could you please tell me why ? thanks!

  • Hi Lisa,

     Actually I can't reproduce your result. I ran the same i2ctmp006_EK_TM4C1294XL_TI example and I see the STOP being issued after NACK is sampled. I wrote my own simple non TI-RTOS I2C master testcase and it is the same.

  • Hi Charles,

    That's my another question, I checked TM4C129 and it did generate STOP. But the same example project, when it ran on TM4C123 and it didn't generate STOP. I check 129 & 123 datasheet, it seems like I2C flow chart is most the same. However, 129 will issue STOP automatically after it got address NACK. I check the software and it is the same software. it is weird... Could you please test it on TM4C123? thanks ~
  • Hi Lisa,

      I'm currently out of office until Thursday. I can't work on the TM4C123 until I come back. However, in the meantime can you not fix the slave address so you can move on with your development. Agree that there is a need to explain why the master is unable to STOP immediately and the subtle difference between TM4C129 and TM4C123. But in my opinion it is not a show stopper. It is more critical to know why the master is not getting ACK'ed. I think the priority for you is to first correct the slave address so proper communication can establish between the master and slave. 

  • Hi Charles,

    Poster speaks of, "I2C bus" yet never describes what other devices (if any) are present & connected.

    The "condition" of the bus - impacted by (all) connected devices - may play a role in generating the NAK.

    Poster proceeds to note, (speaking of 4C129) "But the same example project, when it ran on TM4C123 ... fails."     It is (unexplained) thus unclear - if poster recognizes that the "4C123's I2C ready" condition and (perhaps) other I2C set-up/config. codings are different from the 129's code...

    Long ago - yet "frozen in time here" - past poster, "Bugs worst nightmare" (really) posted a reasonably complete I2C code listing - in which "4C123" (or perhaps - the earlier LX4F MCU) DID respond properly to "illegal addresses" via, "NAK."     That past (successful I2C code) was generated under "StellarisWare" (not the rebrand (TM4C) version) - which may provide a clue to assist (potential) issue's resolution...

  • Hi Charles,

    Customer test our I2C driver and one test is to access unknow device on I2C bus. After this test, customer found out TM4C123 pull SCL low. So customer asked this question and i can duplicate the issue on launchPad.

    I dig out the code and test it. I will issue STOP after i changed code

            if (errStatus & (I2C_MASTER_ERR_ARB_LOST | I2C_MASTER_ERR_ADDR_ACK)) { 
                GPIO_toggle(Board_LED0, Board_LED_OFF); //Lisa
                if (errStatus & I2C_MASTER_ERR_ADDR_ACK)
                {
                    I2CMasterControl(hwAttrs->baseAddr,
                                     I2C_MASTER_CMD_BURST_SEND_ERROR_STOP);
                }
                I2CTiva_completeTransfer((I2C_Handle) arg);
    
            }
    

    However, first I2C data issue repeated START pattern. However, it shouldn't generate repeated START condition since there is no device on bus. Please see the I2C waveform. After set up break point, founding out first transaction, I2CMCS BUSY bit set 1 when we power up TM4C123. Could you please tell me what condition will set  I2CMCS BUSY? thanks

    1.Waveform 

      

    2.

  • Hi Lisa,

     I can replicate in TM4C123. In TM4C123 the master will issue another byte write even after NACK'ed in the address cycle. I tried to write 0xF0 as the first byte data and it is shown in the waveform after the address cycle. 

    For the RTOS version example, I see below waveform. 

    I checked with Amit and he confirms that the I2C module is different between the TM4C123 and TM4C129. The TM4C123 behavior even though not ideal is the expected behavior compared to TM4C129 in this regard.

  • Hi Charles,

    Do we have solution to fix TM4C123 ? Is this Hardware issue ? thanks
  • Hi Lisa,
    Yes this is a hardware issue. We need some more investigation and see if an errata is warranted.
  • Hi Charles,

    thanks for your reply. I didn't see any errata mentioned about this, Could you please double check it ? thanks! 

  • Hi Lisa,
    I meant to say that we can possibly add this to the errata once everything is understood clearly.
  • Hi Charles,

    I found another weird thing on TM4C123GH6PM. When I used same project(i2ctmp006_EK) and readcount =2. I2C will issue a complete write+read waveform even there is no device on bus. Please see below waveform. In general, M4 should get address NACK after wrote address to access unknown device. However, the waveform I captured showed M4 got ACK and change into Read mode. I inserted GPIO to observe read mode/write mode  entry point. It is really weird.  Please see the waveform below. Could you please also check this ? Thanks

    I didn't attach any device on I2C bus. I shouldn't get ACK from device.....

    I2C waveform

    CH3 - write mode entry point

    CH4 - Read mode

  • Hi Lisa,
    I see in your waveform after the 3rd transaction the ACK field is low. Can you use the oscillator scope to confirm it is indeed pulled low?
  • Hi Charles,

    Thanks for your reply. I check the waveform which 9th clock , SDA is low. That mean we get ACK on device. Please see waveform. If I am not right, please let me know. thanks !

  • Hi Lisa,
    I don't dispute what you see in the logic analyzer. I was asking you in my last post if you could confirm using a scope. If the MCU is the only node on the I2C bus then the MCU must have driven this ACK for some reason. Perhaps the kernel got confused into thinking the MCU master is becoming a receiver and trying to tell the slave transmitter that it can still accept data. Your code is doing some writes and reads, right? What if you change your code to only writes but not reads.