TI C2000 I2C Receive with Interrupt not working (Simulink)

Hello,

I have a setup with a ESP32S3 Dev-Module as I²C master and a TI C2000 TMS320F28069M board as a I²C slave. The ESP32 is supposed to send the C2000 several signal. Each signal has three bytes. First a comand byte to separate the signals and then two bytes as payload (uint16 or int16). The C2000-code is implemented in Simulink. In the future, the C2000 shall respond to certain signals with data.

My first issue is that the I2C RCV (Receive) Block outputs my signals in a way that the the byte order changes. For example, the comand byte which is supposed to be always the first byte is sometimes the second or third byte. The order changes throughout restarts and is not predictable. As a solution to this problem I want to use I²C interrupts. This brings me to my second and main question:

I can not get the I²C communication to work with the interrupts. My ESP32 stops sending data as soon as the C2000 code with I²C interrupts is uploaded and running. It seems like the I²C ISR of the C2000 is never called and somehow stops the ESP32 from sending further messages.

To diagnose my problem, I already did the following without success:

• Added a free-running counter in the ISR-function to see if the function gets called. The counter stays at zero.
• Analyzed and used code-fragments of the C2000 c28x_i2c_eeprom_interrupt example in my code.
• Checked I²C with oscilloscope and bus-decoder: Without the Interrupts, the I²C Messages are transmitted and acknowledged. With Interrupt, a successful transmission happens exactly one time, then stops. SCL stays low, SDA stays high.
• Tried different Interrupts, tried different interrupt settings.

My guesses:

• Wrong settings/configuration of ISR/hardware /some registers
• Timing problems
• Some kind of incompactibility between C2000/ESP32
• User error

I attached 4 screenshots of my settings, the my code-example and two screenshots without ISR and two with ISR of my oscilloscope.

I prepared a small Simulink file with my code. If you want to run the code, open "Nur_I2C.slx". Open the subsystem. There are two parts, one with ISR and one without. Just comment one part and uncomment the other. Everything after the delay is for the differentiation of the signals.

Answer 1

[Samhitha]

Hi @Max Udo,

This behavior can be caused by the C2000 I²C slave getting stuck in clock stretching, not by ESP32 incompatibility or timing issues. When the C2000 does not correctly service the I²C interrupt, it holds SCL low, which makes the ESP32 stop transmitting. That’s why you see one successful transfer and then a locked bus with SCL low and SDA high.

The most common cause can be incorrect ISR handling on the C2000. The I²C peripheral requires that RX flags, STOP condition flags, and FIFO states are manually cleared. If the RX FIFO is not fully read, or if flags like RRDY or SCD are not cleared, the peripheral stays active and never releases the bus. This results in a deadlock where the ISR may appear to never be called again.

After the bus locks, check I2CSTR and I2CFFRX registers. You will usually see RX or STOP flags stuck, or RX FIFO not empty confirming the ISR is not servicing the peripheral correctly.

Hope this helps!

[Max Udo]

Thank you for your response.

I will try to access the I2CSTR and I2CFFRX registers in Simulink. Is it right to use "Register ReadWrite" Block under Memory Operations and manually clear the corresponding flags which you mentioned? Shouldn´t the flags automatically be cleared if I tick the option "Clear interrupt status flags after events service" in the hardware mapping browser? Furthermore, I would expect that the ISR is run atleast once, which I think does not happen.

In the meantime I got my code to run with only using the I2C RCV Block with the "I2CINT2A" Interrupt, the "Rx FIFO complete" Event and Rx Interrupt enabled under hardware impementation. I do not think this is pretty nor utilizes the whole potential which the I²C-protocol offers, but it works for my use-case.