GIGA R1 I2C Slave: 500ms SCL Stretching during Address ACK after a Repeated Start

Projects Networking, Protocols, and Devices
1

Hi everyone,

I am using an Arduino GIGA R1 (Mbed-based) as an I2C Slave to emulate a touch IC (Address 0x01). I've encountered a severe performance bottleneck where the GIGA stretches the SCL line for exactly 500ms during a specific communication sequence.

The Context: The host (an automotive head unit) uses a Repeated Start (Sr) to transition from a Write operation to a Read operation without sending a STOP bit.

The Evidence (Logic Analyzer Capture): I have attached a screenshot which clearly shows the "crime scene":

image
image1678×278 10.7 KB

  1. Phase 1 (Write): The GIGA responds normally to Setup Write to [0x01] and receives the data byte 0x04 successfully.
  2. Phase 2 (The Transition): Instead of a STOP bit, the host issues a Repeated Start (SDA goes LOW while SCL is HIGH).
  3. Phase 3 (The Failure): The host immediately sends the Setup Read to [0x01] address.
  4. The Bug: Right after the 8th bit of the Read address, the GIGA pulls SCL LOW for ~500ms before finally releasing it and providing an ACK.

Observations:

  • This happens consistently on both reserved (0x01) and standard (0x11) addresses.
  • The 500ms delay feels like a hard-coded Bus Timeout or a recovery mechanism within the ArduinoCore-mbed layer.
  • My code is minimal (empty onReceive and onRequest handlers), yet the hardware/OS level latency remains.

My Questions:

  1. Is the Mbed OS I2C Slave driver known to have issues handling a "Receiver to Transmitter" role switch during a Repeated Start?
  2. Is there a way to increase the priority of the I2C interrupt or bypass the EventQueue to ensure the onRequest buffer is filled faster?
  3. Where can I find the 500ms timeout constant in the core files to confirm if this is a driver-level reset?

This latency makes the GIGA unusable for any high-speed I2C emulation where the host expects a response within microseconds, not half a second. Any insights or workarounds would be greatly appreciated.

Thanks!

2

Just off the top of my head, isn't there a configurable clock speed? See if this helps

3

"I tried setClock(), but it made things worse. As you can see ：

imgv30211m0e3e9d32-1352-462c-946d-acc9b93aa90g
imgv30211m0e3e9d32-1352-462c-946d-acc9b93aa90g1916×934 200 KB

the GIGA now returns NAK for every single address frame from the host. It seems the Mbed I2C implementation is very sensitive to timing configurations in Slave mode.

I suspect the 500ms stretching is a 'bus recovery' timeout triggered by the core. Does anyone know how to safely bypass the Mbed abstraction and disable the I2C_TIMEOUTR on the GIGA R1 to stop this forced SCL pulling?"

4

HI @zoneyourcalm . Could this git issue be what you're seeing? STM32 I2CSlave race condition causing timeouts · Issue #15498 · ARMmbed/mbed-os · GitHub

The associated PR fix has been applied to ARMs mbed-os repo but Arduino have not applied it to theirs.