Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.38%. Comparing base (6773051) to head (c0e9ac0).
⚠️ Report is 19 commits behind head on master.

@@            Coverage Diff             @@##           master   #18333      +/-   ##==========================================- Coverage   98.38%   98.38%   -0.01%==========================================  Files         171      171                Lines       22297    22294       -3     ==========================================- Hits        21936    21933       -3  Misses        361      361

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report?Share it here.

Code size report:

Reference:  top: Include tools/cc1 in ruff search path. [10b7dfd]Comparison: mimxrt/fsl_lpuart: Use a wrapper function to handle IRQ Idle support. [merge of c0e9ac0]  mpy-cross:    +0 +0.000%    bare-arm:    +0 +0.000% minimal x86:    +0 +0.000%    unix x64:    +0 +0.000% standard      stm32:    +0 +0.000% PYBV10     mimxrt: +1100 +0.292% TEENSY40[incl +72(bss)]        rp2:    +0 +0.000% RPI_PICO_W       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS  qemu rv32:    +0 +0.000% VIRT_RV32

Thank, Anrew. I can test other boards. Is is sufficient to fetch the PR and update the submodules to get the new lib, or do I have to runupdate_sdk.py?

Thanks@robert-hh just the PR checkout and the submodule to the pinned commit should be fine.

Out of interest is there a particular set of tests / peripherals you think are higher risk than others? Have you seen issues on anything specific in the past (other than the uart idle) ?

I do have a rt1010 Dev board and an arch mix (rt1052) here but other than "boots to repl" I'm not sure what tests will add particular value really without extra hardware.

Updated: Fixed UART IRQ Wrapper Implementation

I've updated the wrapper implementation to fix a critical bug whereUART.IRQ_RXIDLE was not firing.

Problem Found

The original single wrapper approach failed because:

1. The SDK'sLPUART_TransferCreateHandle() stores theaddress ofLPUART_TransferHandleIRQ into thes_lpuartIsr[] dispatch table
2. GCC's--wrap flag only intercepts direct functioncalls, not address-of operations (&function)
3. Hardware IRQ handlers call through thes_lpuartIsr[] array, completely bypassing the wrapper

Binary analysis confirmed the wrapper function was compiled but never executed - the SDK function pointer was stored ins_lpuartIsr[] instead.

Solution: Double Wrapper

The fix wraps bothLPUART_TransferCreateHandle andLPUART_TransferHandleIRQ:

void__wrap_LPUART_TransferCreateHandle(LPUART_Type*base,lpuart_handle_t*handle,lpuart_transfer_callback_tcallback,void*userData) {__real_LPUART_TransferCreateHandle(base,handle,callback,userData);// Override SDK's stored function pointer with our wrapper's addressuint32_tinstance=LPUART_GetInstance(base);s_lpuartIsr[instance]=__wrap_LPUART_TransferHandleIRQ;}

This ensures our IRQ wrapper is installed in the dispatch table and actually gets called.

Testing Performed

Tested on SEEED_ARCH_MIX (MIMXRT1052DVL6B) with TX/RX loopback:

IRQ_TXIDLE test (tests/extmod/machine_uart_irq_txidle.py):

• ✅ Passes at 2400, 9600, 115200 baud

IRQ_RXIDLE test (tests/extmod_hardware/machine_uart_irq_rxidle.py):

• ✅ Passes at 2400, 9600, 115200 baud
• Output matches expected results exactly
• Confirms idle line IRQ fires 3-4 character times after data burst

Both tests verified that the wrapper correctly handles SDK 2.16's refactored idle line handling whereLPUART_TransferHandleIDLEReady() only calls the callback whenrxDataSize != 0 (which never happens in ring buffer mode).

Code Size Impact

• Added: 72 lines in machine_uart.c (CreateHandle wrapper + documentation)
• Removed: 2013 lines (deleted hal/fsl_lpuart.c)
• Binary: +160 bytes text (543692 vs 543532 on original wrapper)

Changes

• ports/mimxrt/machine_uart.c: Added__wrap_LPUART_TransferCreateHandle function
• ports/mimxrt/Makefile: Added--wrap=LPUART_TransferCreateHandle to LDFLAGS (2 locations)
• Added detailed comments explaining the double wrapper mechanism

SDK 2.16 Upgrade Validation Summary

Testing Performed

Performed some limited testing on SEEED_ARCH_MIX (MIMXRT1052DVL6B) board:

1. Boot and Console Communication

• Firmware boots successfully to MicroPython REPL
• USB CDC console functional
• Version: v1.27.0-preview.368.g4079b3e71a

2. Peripheral Initialization (Clock System Validation)

• UART(1): 9600 baud initialization successful
• SPI(0): 1MHz initialization successful
• I2C(0): 400kHz initialization successful
• PWM: Frequency generation functional

Confirms PFD clock calculations remain correct despite SDK driver changes

3. SDRAM Memory Subsystem (SEMC Controller)

• Total heap: 32,786,032 bytes (32MB external SDRAM detected)
• 1MB allocation: Successful
• Memory access: Functional (no crashes during extended operation)

4. GPIO Functionality

• Digital output: Pin toggle verified on GPIO_AD_B0_02

5. Virtual Timer

• Timer(-1): Software timer functional

6. RTC (Real-Time Clock)

• Time set/read operations: Functional
• Timekeeping: Verified 2-second advancement

7. Flash Filesystem (FlexSPI Controller)

• File write: Successful
• File read: Content verified correct
• File delete: Successful
• Confirms 852-line FlexSPI driver changes maintain functionality

Testing Limitations

Not Tested:

• Hardware timers (GPT/PIT) - Only virtual timer tested. Hardware Timer(0-3) not enabled for this board.
• DMA/EDMA transfers - I2C, SPI, UART used without DMA. DMA engine changes (137 lines) not validated.
• Networking - No Ethernet or WiFi testing performed.
• USB device/host modes - Only USB CDC (virtual serial) tested. USB device stack and host functionality not validated.
• ADC/DAC - Analog peripherals not tested.
• Deep sleep modes - Power management and low-power modes not tested.
• I2C/SPI data transfers - Only initialization tested, no actual data transmission validated.
• UART data integrity - Flow control, error handling, and high-speed transfers not validated.

Testing Method:
All tests executed via MicroPython scripts over USB CDC console. No low-level driver validation or stress testing performed.