Is there any way to "pace" bytes in an I2C transmission?

[GoEk]

Hi,

I am interfacing to a TI device that requires a 100us delay between each I2C byte and I can't think of any way that doesn't involve "hacking", i.e. using timer delays, interrupts, etc. Is there a more elegant way to do it using the ST I2C implementation? Using CubeIDE on a STM32H750 device.

Regards

Goran

[Tesla DeLorean]

An docs or paper on this part and issues?

Perhaps clock at 10 KHz or less, create some lag on servicing interrupts/callbacks?

[GoEk]

https://www.ti.com/product/MCT8316A

The data sheet does not contain all the quirks of this device, only the "100us" requirement, the rest you will have to search/find on the TI support forum. Actually, 10kHz is the suggested alternative to 100us delay by TI when I asked about it, my problem right now is that after doing the recommend HW updates I can't even get an ACK response from the chip, the bus hangs.

[S.Ma]

Weird slave chipset. Nack on polling is one usual way to tell the host that the slave needs more time. Some sensirion parts had similar limitation which do not comply with the standard, and provide a pre cooked sw driver of gpio bitbang with special sw delays. No need speed when need to wait...

[GoEk]

The device is a TI MCT8316A motor driver. The major impression of this device it that it is "incomplete" (to be nice about it), for example, it uses the I2C General Call address 0x00 as device ID (geeez...). The 100us delay requirement is a "silicon bug that will be fixed in the next chip revision", i.e. the current device is apparently to be considered a Beta version.

[Pavel A.]

STM32H750 RM0433 says that its I2C supports clock stretching. Is this what you're looking for?

[GoEk]

Well, AFAIK clock stretching must be initiated by the slave device and it does not. I get a feeling they have bit-banged the I2C implementation in the device with all the weird requirements.

[Piranha]

For I2C protocol 10 kB/s translates to exactly 100 kbit/s bus speed. Just run the I2C bus at 100 kbit/s mode or slightly slower and you are fine.

[GoEk]

Well, this device doesn't mind 100kbit/s, it "only" requires a 100us delay between each byte which is hard to do. What TI recommends to not have to do this delay is running at 10kbits/s, i.e.1kBytes/s.

[Piranha]

What I meant was that with a 100 kbit/s bus speed the byte period is already 100 us. But it seems that TI actually means an interval, not a period.

[S.Ma]

Make an interrupt base state machine which walk alternatively the timer 100us delay interrupt and the i2c data transfer. You need to dynamically turn on/off each interrupt enable. Both vectors go to the state machine having same interrupt level.

[GoEk]

Well, I see a race condition here since I use the ST HAL functions. I cannot disable interrupts, then call HAL which will enabled them. I also cannot call HAL, then disable interrupts since I theoretically may get interrupted between HAL return and interrupts disable.

However, it may be possible by manipulating the NVIC priority levels for the I2C port sinceST HAL doesn't touch them, i.e. set PrioLevels to highest, call I2C HAL and then 100us later restore prio levels.

A second option might be to disable interrupts globally, call HAL and at return, disable I2C port interrupts and then finally reenabling global interrupts. After 100us, the I2C port interrupts are enabled.

[S.Ma]

Some high end STM32 have DMAMUX which may trigger a byte transfer with a timer trigger signal.....