2175838_en-US

[#1]

S32K344 DMAMUX1 LPUART14 BUS FAULT

Hello,

using S32K344 with Zephyr OS. I set a DTS for LPUART14

DTS: dmas = <&edma0 16 46>, <&edma0 17 47>;
Channel 16,17 should be in DMAMUX1 range, where LPUART14 is on slot 46 and 47.
Unfortunately, when ASYNC API calls callback for a next buffer (immidiatelly after uart_rx_enable)

Any Idea?

ERROR:

[00:00:00.010,000] os: ***** BUS FAULT *****
[00:00:00.010,000] os: Precise data bus error
[00:00:00.010,000] os: BFAR Address: 0x40254000
[00:00:00.010,000] os: r0/a1: 0x4020c000 r1/a2: 0x00048000 r2/a3: 0x0000001a
[00:00:00.010,000] os: r3/a4: 0x0041126c r12/ip: 0x20402888 r14/lr: 0x00404393
[00:00:00.010,000] os: xpsr: 0x01000000
[00:00:00.010,000] os: s[ 0]: 0x0041126c s[ 1]: 0x00404393 s[ 2]: 0x00000010 s[ 3]: 0x00410250
[00:00:00.010,000] os: s[ 4]: 0x00000000 s[ 5]: 0x21000440 s[ 6]: 0x00000000 s[ 7]: 0x20000460
[00:00:00.010,000] os: s[ 8]: 0x00000004 s[ 9]: 0x00000010 s[10]: 0x00000020 s[11]: 0x204094c0
[00:00:00.010,000] os: s[12]: 0x204094c0 s[13]: 0x0040fa28 s[14]: 0x204094c0 s[15]: 0x404a4000
[00:00:00.010,000] os: fpscr: 0x00000000
[00:00:00.010,000] os: r4/v1: 0x20402888 r5/v2: 0x0040fa08 r6/v3: 0x00000011[0m
[00:00:00.010,000] os: r7/v4: 0x20000440 r8/v5: 0x404a401c r9/v6: 0x204021d0
[00:00:00.010,000] os: r10/v7: 0x0000061c r11/v8: 0x00000020 psp: 0x20409418
[00:00:00.010,000] os: EXC_RETURN: 0xfffffffd
[00:00:00.010,000] os: Faulting instruction address (r15/pc): 0x0040dc2c
[00:00:00.010,000] os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:00.010,000] os: Current thread: 0x20401e18 (main)
[00:00:00.618,000] os: Halting system

Re: S32K344 DMAMUX1 LPUART14 BUS FAULT

Hello,

Thank you very much for your help.

I was also communicating with Zephyr and it seems they found a bug in eDMA driver.

https://github.com/zephyrproject-rtos/zephyr/issues/96772

Re: S32K344 DMAMUX1 LPUART14 BUS FAULT

Hello @PavelRydl ,

Thank you for the update and for confirming that the issue persists across multiple S32K344 modules. This helps rule out hardware-related causes.
Based on the faulting instruction inside the EDMA driver (edma_reload_loop) and the crash address (0x4025803c), I have reviewed the EDMA implementation and would like to suggest the following checks and recommendations:

1. Ensure CONFIG_DMA_TCD_QUEUE_SIZE is ≥ 2
The cyclic mode requires at least two TCDs to form a valid loop. If the queue size is set to 1, the reload logic may fail.

2. Validate write_idx bounds before accessing the TCD pool
The driver uses write_idx to index into the TCD pool:
tcd = &DEV_CFG(dev)->tcdpool[channel][data->transfer_settings.write_idx];

Please ensure that write_idx is always less than CONFIG_DMA_TCD_QUEUE_SIZE. You may add a debug log to confirm:
LOG_DBG("write_idx = %d", data->transfer_settings.write_idx);

3. Confirm buffer alignment and size
Your buffer declaration:
__aligned(32) uint8_t async_rx_buffer[2][RX_CHUNK_LEN];
is correct. Just ensure that RX_CHUNK_LEN is a multiple of the data unit size (e.g., 1, 2, or 4 bytes).

4. Disable cyclic mode if not required
If your application does not require cyclic DMA, please ensure:
config->cyclic = false
This will avoid triggering the edma_reload_loop() logic entirely.

5. Enable DMA error IRQ and check error flags
Make sure the DTS does not disable error IRQs (no_error_irq = false). Then monitor:
EDMA_GetErrorStatusFlags(...)
for any reported faults during runtime.

6. Use basic DMA mode for initial testing
If cyclic or scatter-gather is not needed, consider using the basic configuration path:
dma_mcux_edma_configure_basic(...)
This simplifies the setup and avoids complex reload logic.

Best regards,

Pavel

Re: S32K344 DMAMUX1 LPUART14 BUS FAULTI tested other module with s32k344 and same problem. It's not a hardware problem.Re: S32K344 DMAMUX1 LPUART14 BUS FAULT

Hello,

"If the issue persists, try replacing the DMA-based RX with polling temporarily to confirm that the UART peripheral itself is functional and the issue is isolated to DMA usage."

Actually, I Used interrupt-driven uart before and it's working fine. I need DMA becuase of high CPU usage and interrupt based uart is not reliable enough, mostly becuase of really small RX FIFO buffer (4 words)

"Verify uart_rx_buf_rsp() is not called too early"

tested, same problem. Also, this request next buffer and I should provide it as fast as possible.

"Try using async_rx_buffer[0] instead of [1]"

Tested, but same problem. Reference manual says I should not bind to the same memory, so I still have to use different part of memory for a next buffer.

"Try reducing the buffer size"

Tested. same problem.

I have no idea, what I should do now

Is it a bug in a NXP drivers? It's strange, MUX0 is fine, only MUX1.

It's really like DMA cannot access somewhere, but that a bit above my current nxp knownledge to solve that.

Thank you for helping me!

Re: S32K344 DMAMUX1 LPUART14 BUS FAULT

Hello @PavelRydl ,

Thank you sharing details.

Please find my hints below:

1. Check buffer alignment and cache settings
In your code, the buffer is declared as:

__nocache __aligned(32) uint8_t async_rx_buffer[2][RX_CHUNK_LEN];

This is correct and should be DMA-safe. However, please verify that:

 - RX_CHUNK_LEN is a multiple of 32 (it is 32, so OK).
 - The buffer is not being accessed concurrently from another context (e.g., logging or polling).

2. Verify uart_rx_buf_rsp() is not called too early
Even though the callback is triggered only once, it's possible that the DMA controller hasn't finished setting up the initial transfer when uart_rx_buf_rsp() is called. Try delaying the response slightly:

case UART_RX_BUF_REQUEST:
         k_sleep(K_MSEC(1)); // Small delay before responding
         uart_rx_buf_rsp(dev, async_rx_buffer[1], RX_CHUNK_LEN);
         break;

3. Try using async_rx_buffer[0] instead of [1]
Since [0] is the initial buffer used in uart_rx_enable(), and [1] is never used before the crash, try responding with [0] to rule out any issues with [1]:

uart_rx_buf_rsp(dev, async_rx_buffer[0], RX_CHUNK_LEN);

4. Try reducing the buffer size
Although 32 bytes is small, try using 16 or 8 bytes to see if the crash behavior changes. This can help isolate whether the issue is size-related.

5. Optional Debug Step
If the issue persists, try replacing the DMA-based RX with polling temporarily to confirm that the UART peripheral itself is functional and the issue is isolated to DMA usage.

Best regards,

Pavel

Re: S32K344 DMAMUX1 LPUART14 BUS FAULTFaulting instruction address:
.text.edma_reload_loop
0x00000000004030b8 0x1f4 zephyr/drivers/dma/libdrivers__dma.a(dma_mcux_edma.c.obj)Re: S32K344 DMAMUX1 LPUART14 BUS FAULT

Hello,

I did some changes.

1. I removed that variable, I don't need it.

2. The request is called only once and it crashes, so I will never assign same buffer again

3. It's not in any special section, just bss, I tried to use nocache just for a test with same error

4. I verified slots again

46	LPUART14	Transmit DMA Request
47	LPUART14	Receive DMA Request

5. Added

6. Added

Error:

*** Booting Zephyr OS build 69ce66d49133 ***
[00:00:00.020,000] dma_mcux_edma: edma_log_dmamux: DMAMUX CHCFG 0x0
[00:00:00.020,000] dma_mcux_edma: dma_mcux_edma_get_status: DMA MP_CSR 0x3000d0
[00:00:00.020,000] dma_mcux_edma: dma_mcux_edma_get_status: DMA MP_ES 0x0
[00:00:00.020,000] dma_mcux_edma: dma_mcux_edma_get_status: DMA CHx_ES 0x0
[00:00:00.021,000] dma_mcux_edma: dma_mcux_edma_get_status: DMA CHx_CSR 0x0
[00:00:00.021,000] dma_mcux_edma: dma_mcux_edma_get_status: DMA CHx_ES 0x0
[00:00:00.021,000] dma_mcux_edma: dma_mcux_edma_get_status: DMA CHx_INT 0x0
[00:00:00.021,000] dma_mcux_edma: dma_mcux_edma_get_status: DMA TCD_CSR 0x0
[00:00:00.021,000] dma_mcux_edma: dma_mcux_edma_configure: channel is 18
[00:00:00.021,000] dma_mcux_edma: dma_mcux_edma_configure: INSTALL call back on channel 18
[00:00:00.021,000] dma_mcux_edma: dma_mcux_edma_start: START TRANSFER
[00:00:00.021,000] dma_mcux_edma: edma_log_dmamux: DMAMUX CHCFG 0xaf
[00:00:00.022,000] async_api: uart_callback: EVENT: 3
[00:00:00.022,000] os: ***** BUS FAULT *****
[00:00:00.022,000] os: Precise data bus error
[00:00:00.022,000] os: BFAR Address: 0x4025803c
[00:00:00.022,000] os: r0/a1: 0x4020c000 r1/a2: 0x0004c000 r2/a3: 0x0000403c
[00:00:00.022,000] os: r3/a4: 0x40254000 r12/ip: 0x20401344 r14/lr: 0x0040316f
[00:00:00.022,000] os: xpsr: 0x01000000
[00:00:00.022,000] os: s[ 0]: 0x00000000 s[ 1]: 0x00000004 s[ 2]: 0x20402800 s[ 3]: 0x20402810
[00:00:00.023,000] os: s[ 4]: 0x00000000 s[ 5]: 0x0000000f s[ 6]: 0x00000000 s[ 7]: 0x204027f0
[00:00:00.023,000] os: s[ 8]: 0x204027f0 s[ 9]: 0x0040d2b0 s[10]: 0x20402810 s[11]: 0x204027f0
[00:00:00.023,000] os: s[12]: 0x00000000 s[13]: 0x00401b87 s[14]: 0x0040d2f0 s[15]: 0x00401393
[00:00:00.023,000] os: fpscr: 0x0040e318
[00:00:00.023,000] os: r4/v1: 0x20401344 r5/v2: 0x00000012 r6/v3: 0x0040ca68
[00:00:00.023,000] os: r7/v4: 0x20000480 r8/v5: 0x404a401c r9/v6: 0x20400520
[00:00:00.029,000] os: r10/v7: 0x00000678 r11/v8: 0x00000020 psp: 0x20402750
[00:00:00.029,000] os: EXC_RETURN: 0xffffffed
[00:00:00.029,000] os: Faulting instruction address (r15/pc): 0x0040317a
[00:00:00.029,000] os: >>> ZEPHYR FATAL ERROR 25: Unknown error on CPU 0
[00:00:00.029,000] os: Current thread: 0x20400940 (main)
[00:00:00.029,000] os: Halting system

Tried to use different channel

dmas = <&edma0 17 46>, <&edma0 18 47>;

Re: S32K344 DMAMUX1 LPUART14 BUS FAULT

Hello @PavelRydl ,

Thank you for the detailed report. Based on the provided logs and code snippet, here are a few suggestions:

1. Initialize async_rx_buffer_idx before use
Ensure that async_rx_buffer_idx is explicitly initialized to 0 before calling uart_rx_enable(). Uninitialized global variables may lead to undefined behavior.

async_rx_buffer_idx = 0;

2. Correct buffer selection in UART_RX_BUF_REQUEST
In the callback, you're always responding with async_rx_buffer[1], regardless of the current index. This may cause the driver to use an invalid or already active buffer. Instead, use the current index and toggle it after responding:

uart_rx_buf_rsp(dev, async_rx_buffer[async_rx_buffer_idx], RX_CHUNK_LEN);
async_rx_buffer_idx ^= 1; // Toggle between 0 and 1

3. Verify DMA buffer location
Ensure that async_rx_buffer is located in a memory region accessible by the DMA controller (typically in SRAM, not in .noinit or other special sections). Misplaced buffers can cause bus faults during DMA access.

4. Double-check DMA channel and DMAMUX slot mapping
While channels 16 and 17 should be valid for DMAMUX1, please verify that:
- These channels are not used by other peripherals.
- The DMAMUX slot numbers 46 and 47 are correctly mapped to LPUART14 RX/TX in your SoC's reference manual and Zephyr's SoC integration.

5. Add a short delay before enabling RX
In some cases, adding a small delay before calling uart_rx_enable() can help avoid race conditions between peripheral and DMA initialization:

k_sleep(K_MSEC(10));
uart_rx_enable(...);

6. Enable DMA and UART debug logs
To get more insight into what happens before the crash, consider enabling debug logs for DMA and UART in your prj.conf:

CONFIG_DMA_LOG_LEVEL_DBG=y
CONFIG_UART_LOG_LEVEL_DBG=y

Best regards,

Pavel