S32G274 I2C clock anomaly, half of a clock cycle is missing

[zyz]

During the development with the S32G274 chip (MCAL version SW32G2_RTD_4.4_2.0.0_HF02), we encountered an abnormal I2C clock issue, which manifests as follows:

In the communication process, it was discovered that certain clock cycles were approximately halved, abnormally shortened, with the high-level duration almost at zero.

From the oscilloscope waveform capture, it appears that the SCL line is pulled low before it fully goes high. What could be causing this?

[Daniel-Aguirre]

Hi,

Is this a custom board? Or can it be reproduced with an NXP reference board?

Can you help us verify that this behavior does not occur on newer RTD versions? Since RTD v2.0.0 HF04 is an old release, newer releases might have implemented patches, which can solve this kind of situations.

Please, let us know.

[zyz]

Yes, this is equipment that we developed in-house, without the use of a development board. Furthermore, the occurrence of this phenomenon is quite rare.

We are planning to verify whether this issue persists with a new RTD version next. Additionally, I would like to ask if it's possible for external factors to influence this phenomenon. However, according to my understanding, even if external interference were to pull the SCL low at that moment, from the perspective of baud rate, there shouldn't be a loss of what was supposed to be a period of high level.

Or if the SCL is pulled down at this moment, the chip will obtain the current SCL state and start to calculate the time of the next inversion, resulting in the loss of the time that was originally high?

[Daniel-Aguirre]

Hi,

Thanks for your feedback.

As for external factors, interference in the line might create noisy signals but not pulling to GND (at least the common ones). We understand that another possibility of this behavior might the slave trying to do a clock stretching, you can verify if your slave device can do clock stretch and either disable under your device it or enable it under S32G.

The SCL can only be taken as a 1 if it goes above the defined voltage value under the I²C specification. If it cannot reach this value (and comply with the required timing requirements), we cannot ensure that the data will be read correctly.

Please, let us know.

[zyz]

Hello, I have two questions.

Firstly, I couldn’t find any description in the S32G manual about enabling or disabling the I2C clock stretching feature. Does S32G support this configuration, or is it supported by default?

Secondly, if this phenomenon was caused by slave device clock stretching, it should slow down the transmission rather than causing the loss of time corresponding to the high phase of the clock. However, based on the waveform that I’ve captured from my side, it seems like the time that should correspond to a certain clock's high phase is missing. For example, assuming an I2C baud rate set at 400KHz would mean each clock cycle is 2.5us but in the moment shown in the picture where there was a problem, what should have been approximately 1.25us of time for high phase directly disappeared—leaving only 18.75us for transmitting 8 bits instead of the expected 20us. This part confuses me and I don't quite understand how it's processed internally by S32G.

[Daniel-Aguirre]

Hi,

Thanks for your feedback. It seems that the clock stretching is available by default. The following is told under the S32G2 RM [Page 2198, S32G2 Reference Manual, Rev. 8, February 2024]:

" Slave devices may hold the SCL low after completion of one byte transfer (nine bits). In such cases, it halts the bus clock and forces the master clock into wait state until the slave releases the SCL line. "

As for the phenomenon, we can recommend trying to reduce the baudrate to verify if it happens even if the baudrate is lower. Again, this might be related to the RTD version, and given that this behavior is not constant, can be difficult to pinpoint the exact problem.

We do apologize.

Please, let us know.

[zyz]

Hello, after we lowered the I2C baud rate on our side, it seems that the issue has been resolved. However, I can't understand why such a waveform appeared. If it were a clock stretching problem, it shouldn't lose half a clock pulse; rather, the clock width should extend.