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
Below is the configuration for printing. Which parameter may need to be adjusted?
PS:apparently due to automatic interface allocation
A 10 MHz LPI2C functional clock is not listed in the RT1064 Reference Manual example timing configurations for 400 kbps.
Although it is possible to generate a 400 kbps baud rate with this clock, the automatically generated timing parameters should be carefully verified against the I2C specification, particularly with respect to tLOW, tHIGH, setup/hold timing, and data valid timing.
To reduce design risk, it is recommended to use a validated clock source, such as 48 MHz, as shown in the Reference Manual.
I tried modifying 60MHz and 8MHz, but it still didn't work. The red box in the figure below shows the values printed after modification, which are different from the manual
Hi @foreverwlh2025 ,
There are several ways to configure the I2C clock.
As a suggestion, you can try 8 MHz and 60 MHz, as these two clock settings are relatively easy to achieve.
I am using the SDK demo:
"evkmimxrt1064_lpi2c_edma_b2b_transfer_master"
Way 1: Configure LPI2C clock source to 60 MHz
Simply set the clock divider to 0.
Way 2: Configure LPI2C clock source to 8 MHz
Use the MCUXpresso IDE Clock Tool and configure it as shown below. Select OSC_CLK as the clock source and set the divider to 3, which will generate an 8 MHz clock for the LPI2C (I2C) module.
Wish it helps you
Best Regards
May
Hi @foreverwlh2025 ,
For example, when using a 60 MHz I2C clock, the following configuration can be applied.
Wish it helps you
Best Regards
May
The current I2C clock is configured based on the sample configuration in the SDK2_13_0-EVK-MIMXRT1064 \ boards \ evkmimxrt1064 \ river_deamples \ lpi2c directory,
#define LPI2C_CLOCK_SELECT (0U)
#define LPI2C_CLOCK_DIVIDER (5U)
CLOCK_SetMux(kCLOCK_Lpi2cMux, LPI2C_CLOCK_SELECT);
CLOCK_SetDiv(kCLOCK_Lpi2cDiv, LPI2C_CLOCK_DIVIDER);
---How can I modify it to obtain the precise 8MHz or 48MHz? (The clock tree doesn't seem to be visible)
As shown in the diagram, I tried to modify the register settings to correspond to the parameters, but there was no improvement at 60MHz; Even good modules cannot function properly at 8MHz
However, the isolator chip we are using does not support SCL bidirectional. After replacing the isolator chip,
the test was normal; This order can be closed