On a Teensy (MXRT1062) I've bypassed the Zephyr I2C drivers and am using the NXP SDK provided by Zephyr SDK version 0.17.4 (mcux-sdk-ng) directly. I.e. the functions implemented in:
modules/hal/nxp/mcux/mcux-sdk-ng/drivers/..:
.. /edma/fsl_edma.c
.. /dmamux/fsl_dmamux.c
.. /lpi2c/fsl_lpi2c.c
.. /lpi2c/fsl_lpi2c_edma.c
... etc.
The Teensy LPI2C master talks to several (types of) slave devices.
In 'blocking'/'synchronous' mode I can run this setup for days without a problem - LPI2C transactions occuring in the 100's of Hz.
When I setup the same LPI2C transactions (and same hardware) to use the eDMA engine ... things run normally for about 10 minutes to an hour before hanging.
Even when I slow the DMA frame rate down to a fraction of the 'synchronous' mode rate, the bus hangs in relatively short order.
This happens using multiple (types) of slave devices, even when the bus is reduced to just one slave device.
The hang is initiated by a kStatus_LPI2C_PinLowTimeout event received by the EdmaCompletionCallback (registered with LPI2C_MasterCreateEDMAHandle(...)).
Once that happens, I can't seem to do anything short of power-cycling the system to get back to normal.
A 'soft reset' routine that consists of :
* clearing MIER, MDER
* calling LPI2C_MasterTransferAbortEDMA(), EDMA_AbortTransfer(), LPI2C_MasterReset(), LPI2C_MasterClearStatusFlags()
* flushing FIFOs in MCR
* and re-initializing with LPI2C_MasterInit()
is called whenever the DMA completion callback is not called by its deadline. The 'soft reset' routine has absolutely no effect.
No more completion events occur after the first kStatus_LPI2C_PinLowTimeout event. In the LPI2C.MSR, the BBF bit (bus busy flag) is permanently set.
The Teensy reset button does not reset this state - a power cycle is required in order to talk to the slave(s) again.
Hoping someone can provide some insights:
* Is there a bug in the mcux-sdk-ng SDK that someone might have patch for?
* Why do the same rock-solid synchronous transactions fail under eDMA control?
* Is there some eDMA setup I can do that prevents the kStatus_LPI2C_PinLowTimeout from happening (increasing pinLowTimeout_ns doesn't help)? Clock stretching has been disabled for all slaves.
* Is there a quick recovery approach I can apply - short of wiggling the SDA line 9 times or whatever?
Thanks for any support!
--George
Hi @zeebrog ,
Thank you so much for your interest in our products and for using our community.
Q1:* Is there a bug in the mcux-sdk-ng SDK that someone might have patch for?
A1: No. Based on available documentation, there is no reported erratum for LPI2C + eDMA on RT1060.
Q2* Why do the same rock-solid synchronous transactions fail under eDMA control?
A2:Blocking mode may appear more stable not because DMA timing is less precise, but because the blocking path observes FIFO progress and LPI2C status synchronously in software. In LPI2C controller mode, DMA only services TX/RX FIFO requests, while error conditions such as unexpected NACK, arbitration loss, FIFO error, or pin-low timeout still require software handling before a new START can proceed. So under abnormal target behavior or bus fault conditions, the DMA path is typically more dependent on correct driver state handling and recovery sequencing.
Q3:* Is there some eDMA setup I can do that prevents the kStatus_LPI2C_PinLowTimeout from happening (increasing pinLowTimeout_ns doesn't help)? Clock stretching has been disabled for all slaves.
A3：Not directly, The PINLOW timeout only affects when the timeout flag is triggered, not the root cause of the bus being stuck.
Q4* Is there a quick recovery approach I can apply - short of wiggling the SDA line 9 times or whatever?
A4：A recommended method is to first abort or disable the LPI2C master and reset its internal state( for example by clearing MCR[MEN] or asserting MCR[RST] ).
If the bus remains physically stuck low after that, in practice, manually pulsing SCL while leaving SDA released may be used as a generic I2C bus-recovery workaround to let a slave complete an unfinished transfer and release the bus.
Best Regards
May
I think the key point is that LPSPI and LPI2C are fundamentally different interfaces. LPI2C is a bus-oriented interface with protocol-level interactions such as arbitration, ACK/NACK handling, and clock stretching, and it defaults to open-drain signaling. LPSPI, in contrast, is a synchronous serial interface.
For LPSPI on RT1062, choosing between blocking and eDMA transfer is not about one being inherently more robust than the other. It mainly depends on your system architecture, resource allocation, and application requirements. Blocking keeps transfer handling in the software path, while eDMA is intended to offload FIFO register access and reduce CPU overhead.
So the selection should be based on how your application balances CPU usage, timing requirements, and software complexity.
Hello May Liu -
A little surprised by this answer:
A2: Blocking mode is more robust because the CPU services the FIFO directly. In eDMA mode, FIFO handling depends on DMA timing, which can increase the chance of TX underrun or RX overrun, causing the bus to stall.
The DMA runs in a hardware/interrupt context that should have more precise timing than anything at the "CPU services" level. And even though the table you included has DMA = 'y' only for TX and RX FIFO events that should be sufficient to build a stable interaction on a single-master bus, with strong signals, and well behaved slaves.
If what you are saying is true, than the DMA feature for I2C on the i.MXRT1062 is pretty much useless without constant recovery sequences which aren't going to work in any time critical applications.
I will continue to look for (and hope for) a software bug in the NXP SDK driver(s).
Best, George
Sorry - one more question.
The other option is to move to LPSPI -
Do you see similar limitations using the DMA with LPSPI on the i.MXRT1062?
There is a circular FIFO feature there which looks to be a completely 'CPU hands off solution' for managing a small amount of data. Do you anticipate that to be more robust than an LPSPI blocking transfer?
Thanks, George
Blocking mode may appear more stable not because DMA timing is less precise, but because the blocking path observes FIFO progress and LPI2C status synchronously in software. In LPI2C controller mode, DMA only services TX/RX FIFO requests, while error conditions such as unexpected NACK, arbitration loss, FIFO error, or pin-low timeout still require software handling before a new START can proceed. So under abnormal target behavior or bus fault conditions, the DMA path is typically more dependent on correct driver state handling and recovery sequencing.
Hi May Liu ,
Thanks for your answers.
Zephyr 4.4.0 was just released in April. As mentioned previously, I have been using 4.3.0 (released Nov. 2025).
I replaced just the fsl_lpi2c.c/.h and fsl_lpi2c_edma.c/.h files from my 4.3.0 release with those found in the NXP SDK folder from 4.4.0. (BTW - I tried to get the 'latest' versions of these files from the NXP on-line SDK builder, but it would always generate older versions of these files than those found even in the 4.3.0 release).
There were also some changes in fsl_edma.c/.h ... but I didn't replace those because other DMA driven peripherals seem to be working fine.
The result -
The same array of sensors on the I2C bus (that ran endlessly in synchronous mode) but ended up hanging the bus in 10 or 15 minutes in DMA mode, now ran for four days straight in DMA mode (almost 10 million I2C transactions) before I stopped the test. That's more like it!
Best, George