The I2C2 interface of the RT1064 device connects to Module A. Communication anomalies occur at 400kHz, but it functions properly at 100kHz
1. Connecting module B of a different model within the same series at 400kHz is no problem
2. In terms of waveform, it is equivalent to an anomaly occurring when the host clock is stretched and then restored after connecting to Module A
PS: Implement the I2C driver port of the device to another 1064 device, test module A, no issues at 400k
What might be the reason？
1. Figure 1 Module A Abnormal Waveform of Logic Analyzer at 400kHz
2. Figure 2: Waveform of Logic Analyzer for Module A at 100kHz
3. Figure 3: Waveform of Module B at 400kHz
Hi @foreverwlh2025 ,
From your observations, the issue appears more likely to be related to insufficient 400 kHz I2C timing margin caused by the two-stage ADUM1251 isolation link, rather than an abnormality of Module A itself.
Even if the rise time is within spec, on RT1064, we still recommend checking the LPI2C master-side 400 kHz configuration, especially MCFGR2[FILTSCL/FILTSDA] and MCCR0/MCCR1 , because the master synchronization latency on RT1064 is affected not only by rise time, but also by the digital filter and timing parameter settings.
We suggest reading out the actual configuration used in your project and comparing it with Table 47-5, “LPI2C Example Timing Configurations,” in Chapter 47 of the RT1064 Reference Manual .
In particular, please check whether the following settings match to the example values for your selected clock condition:
- I2C module clock source
- Target baud rate: 400Kbps
- PRESCALE
- FILTSCL / FILTSDA
- SETHOLD
- CLKLO
- CLKHI
- DATAVD
Wish it helps you
Best Regards
May
Additional information, there was some progress in positioning yesterday:
Our hardware expansion is:
Motherboard: RT1064--- ADUM1251 3.3 V to 5 V
Subboard: ADUM1251- Module A 5v to 3.3v
After verification, it was found that after adding ADUM1251 to the two layers of the hardware link, module A had abnormal communication. However, after removing it, communication returned to normal at 400k. What could be the reason for this？
PS: Our hardware engineers believe that ADUM1251 only increases communication latency and has no other impact
Our product is about to be released, and we have been investigating this issue for several days. If we could receive your response as soon as possible, we would greatly appreciate it！
Hi
Supplementary information
1. Our two hardware engineers checked the waveform of the problem through an oscilloscope, and the rise time met the requirements, within 100+ns
2. I ported I2C initialization and read-write function drivers to another type of RT1064 device, and tested module A without any issues
The following figure shows the waveform of another device module A testing logic analyzer
doubt:
1. If the clock recovers abnormally after stretching, what other reasons could be causing it
2. Is there a dedicated function to set settings such as MCFGR2 mentioned in the last reply? I didn't see any interface to be set in the I2C initialization process
----If the rise time is met, do we not need to consider these register settings？
Hi @foreverwlh2025 ，
Thank you so much for your interest in our products and for using our community.
I think that this is most likely not a Module A issue, but a 400 kHz timing-margin issue on that specific RT1064 LPI2C2 bus.
On RT1064, LPI2C timing is affected by bus rise time, bus loading, pull-up resistors, and glitch-filter latency.
RT1064RM reference manual describe that larger rise time increases synchronization latency. (refer to chapter 47.3.1.4 Timing Parameters)
The master glitch filters MCFGR2[FILTSCL/FILTSDA] must be set so their latency stays below the minimum SCL low/high period, and RT1064 provides example 400 kbps timing settings in MCCR0/MCCR1 . Please check the Table 47-5. LPI2C Example Timing Configurations
So if Module A makes the bus edges slightly slower or changes the effective loading, the bus may fail at 400 kHz but still work at 100 kHz .
Wish it helps you
Best Regards
May