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.

TM4C1294NCPDT: I2C slave: when is NACKing possible?

Part Number: TM4C1294NCPDT

Hi,

I am currently implementing a small I2C slave that shall demonstrate I2C communication to students who implement the master part and communicate with the slave (in loopback mode, but I have currently set it up with external pull ups for debugging). To that end I would like the implementation to behave as nice as possible regarding error detection/propagation, i.e. I want to NACK whenever the master is not behaving as intended whenever possible. My slave implements a typical register-based device, i.e. the master needs to address the slave via I2C and then write a register address before it can eventually read or write to that register of the slave.

It basically works but I would like to return more NACKs than I currently do. However, there are some situations where my slave code stalls the master instead of NACKing and making it abort the transaction, which I don't understand. For example, when I am serving a I2C_SLAVE_ACT_TREQ in a I2C_SLAVE_INT_DATA interrupt I would like to NACK this request instead of returning data (an then NACK which I think works). To that end, I tried to execute I2CSlaveACKValueSet(..., 0) instead of I2CSlaveDataPut(). However, when I do so the transaction (as shown by a logic analyzer) comes to a hold after the addressing byte is sent by the master and an ACK by the slave - mind you, although I tried to NACK. I presume the stall is due to clock stretching by the slave but I am not sure. I wonder if what I try is possible at all with the TM4C1294NCPDT slave at all. Basically, I would like to know at which instants calling I2CSlaveACKValueSet() has an effect because neither the MCU datasheet nor TivaWare documentation go even near that amount of details.

  • Years ago firm & I attempted the design of, "Multi-Serial Mode Diagnostic Device - with a Display." (Display reported success or failure - and clearly reported (in English) the user's error.) And - strikingly similar to your results - we achieved success for the "easy" - not so much for the more difficult of (both) I2C & CAN operation. (ours included UART, SPI, I2C, & CAN.)

    In the end - we implemented (most) of those "involved functions" by "abandoning the built-in I2C/MCU support - and resorting to bit-banging.      We sold to less than 10 schools - (one tenth of our goal - and found (other) concrete structures - which invited our (hard) heads.)

    One thing which really helped - we read the pertinent data from MULTIPLE ARM vendors (so rarely done here) - and that was the ONLY means by which we were able to "tease out" the level of data - really required...

    Then (with us) - as is now (with you) the I2C Slave implementation unduly aged us - and caused many "missed" evening engagements... (have you (possibly) a smaller rock - or a shorter mountain?)       (i.e. Do you (really) need ALL of those (very) minority I2C "use cases" - do you believe that (great) extra effort will be "recognized" and pay off?)