The timeout for i2c master is similar to clock stretching, but different for i2c slave side.
Seems esp32 slave doesn't support hardware clock stretching. (which will be supported on esp32s2 and later chips)
and this one from stickbreaker:
the only way to extend the clock stretching hardware limit of 13ms is to reduce the processor clock speed. the maximum timeout period is 2**20 APB clock cycles. APB clock is either 80MHz or CPU clock, whichever is slower. But, WiFi/Bluetooth does not function if APB clock is less than 80MHz.
The ESP32 for this PR is the master I2C device, talking to the Infineon 9673.
Although I did not implement any clock stretching in this PR, there are some adjustable delays between write-then-read, and after retries:
This is the initial I2C TPM support for the Infineon Optiga 9673 TPM2 on the Espressif ESP32.
Note there's a newer I2C implementation noted in the latest Espressif documentation. The PR does not use that library yet, but instead utilizes the older library used in the Espressif v5.2 I2C examples which is compatible with a wider range of ESP-IDF versions.
The included example directly references the /examples/native/native_test.c to demonstrate using the TPM on the ESP32.
Support for the newer I2C library as well as SPI will be submitted in separate future pull requests.
This library is expected to work with all flavors of the ESP32-[C2/C3/C6/S2S6, etc.], but has only been tested on the basic Xtensa ESP32 at this time.
Edit
This PR as-is appears to be working reliably. For future reference:
After I submitted this PR, I bought a few LetsTrust TPM for Raspberry Pi devices. The folks at https://letstrust.de/ reached out to me today with an interesting question & comment:
I did not explicitly enable any clock stretching.
See the api-reference/peripherals/i2c docs and https://github.com/espressif/esp-idf/issues/4173 - in particular the comment from
costaud
:and this one from
stickbreaker
:The ESP32 for this PR is the
master
I2C device, talking to the Infineon 9673.Although I did not implement any clock stretching in this PR, there are some adjustable delays between write-then-read, and after retries:
Adding some details on my
sdkconfig.h
... all the defaults resulting in these settings that may be of interest:See also I2C clock is not generate reliably after clock stretch