topic LPSPI3 + eDMA4 Transfer Issue on i.MX93 EVK (M33 Core) in i.MX Processors

topic LPSPI3 + eDMA4 Transfer Issue on i.MX93 EVK (M33 Core) in i.MX Processors https://community.nxp.com/t5/i-MX-Processors/LPSPI3-eDMA4-Transfer-Issue-on-i-MX93-EVK-M33-Core/m-p/2346223#M244795 <P>Hello,</P><P>I am currently testing an external ADC (ADS131E08) functionality using the i.MX93 EVK. I have already confirmed that the LPSPI3 interface works fine in Polling/Interrupt mode. Now, I am trying to implement LPSPI3 combined with eDMA4 to optimize performance.</P><P>Environment:</P><P>Target Board: MCIMX93-EVK (Cortex-M33)</P><P>SDK Version: MCUXpresso SDK 25.12.0</P><P>IDE: VSCode with MCUXpresso Extension</P><P>Since there is no specific "LPSPI-EDMA" example for i.MX93 in the SDK, I implemented the following based on other peripheral examples:</P><P> </P><P>1. Memory Allocation (OCRAM - NonCacheable)</P><P>I placed all DMA-related buffers and handles in the OCRAM section and configured the MPU as Non-Cacheable to avoid coherency issues.</P><P>============================ code ===============================</P><P>/* Linker Script */ MEMORY { m_data (RW) : ORIGIN = 0x20003000, LENGTH = 0x0001B000 m_ocram (RW) : ORIGIN = 0x20480000, LENGTH = 0x00040000 } .noncacheable_section : { . = ALIGN(32); __noncacheable_start__ = .; *(NonCacheable) __noncacheable_end__ = .; } > m_ocram</P><P>/* Variable Definitions */ __attribute__((section("NonCacheable"), aligned(32))) static lpspi_master_edma_handle_t g_lpspi_master_edma_handle; AT_NONCACHEABLE_SECTION_INIT(static edma_handle_t g_lpspi_tx_dma_handle); AT_NONCACHEABLE_SECTION_INIT(static edma_handle_t g_lpspi_rx_dma_handle); __attribute__((section("NonCacheable"), aligned(32))) static uint8_t dummy_tx_data[ADC_SAMPLE_BYTES] = { ... }; __attribute__((section("NonCacheable"), aligned(32))) static uint8_t sample_buf_ping[INTERPOLATION_L][ADC_SAMPLE_BYTES];</P><P>============================ code ===============================</P><P> </P><P>2. Initialization Process</P><P><SPAN>I configured eDMA4, created handles, and linked them to LPSPI3.</SPAN></P><P>============================ code ===============================</P><P>static void LPSPI_Master_DMA_Init(void) { edma_config_t userConfig; EDMA_GetDefaultConfig(&userConfig); EDMA_Init(DMA4, &userConfig); EDMA_CreateHandle(&g_lpspi_tx_dma_handle, DMA4, LPSPI3_TX_DMA_CHANNEL); // CH 12 EDMA_CreateHandle(&g_lpspi_rx_dma_handle, DMA4, LPSPI3_RX_DMA_CHANNEL); // CH 13 EDMA_SetChannelMux(DMA4, LPSPI3_TX_DMA_CHANNEL, kDma4RequestMuxLPSPI3Tx); EDMA_SetChannelMux(DMA4, LPSPI3_RX_DMA_CHANNEL, kDma4RequestMuxLPSPI3Rx); LPSPI_MasterTransferCreateHandleEDMA( LPSPI3, &g_lpspi_master_edma_handle, LPSPI_MasterUserCallback, NULL, &g_lpspi_rx_dma_handle, &g_lpspi_tx_dma_handle); }</P><P>============================ code ===============================</P><P> </P><P>3. SPI Transaction with Address Conversion</P><P>I used MEMORY_ConvertMemoryMapAddress to provide the System Address (Local2DMA) to the eDMA engine.</P><P>============================ code ===============================</P><P>xfer.txData = (uint8_t *)MEMORY_ConvertMemoryMapAddress((uint32_t)dummy_tx_data, kMEMORY_Local2DMA); xfer.rxData = (uint8_t *)MEMORY_ConvertMemoryMapAddress((uint32_t)sample_buf_ping, kMEMORY_Local2DMA); xfer.dataSize = ADC_SAMPLE_BYTES; xfer.configFlags = kLPSPI_MasterPcs0; status_t ret = LPSPI_MasterTransferEDMA(LPSPI3, &g_lpspi_master_edma_handle, &xfer);</P><P>============================ code ===============================</P><P> </P><P>Current Symptoms:</P><P>The first call to LPSPI_MasterTransferEDMA returns kStatus_Success, but no SPI clock or data is observed on the oscilloscope.</P><P>From the second call onwards, it consistently returns kStatus_LPSPI_Busy. This suggests that the driver's internal state is stuck in 'Busy' because the first transfer never completed or triggered the 'Transfer Done' interrupt.</P><P>Checking the eDMA4 registers:</P><P>TCD[12].CH_CSR (ERQ bit) is 0 (or not being set properly).</P><P>CH_ES (Error Status) sometimes shows DBE (Destination Bus Error).</P><P>The LPSPI3 DER register has TDDE and RDDE bits set to 1 after the first call, meaning the SPI peripheral is requesting DMA, but the eDMA engine is not responding.</P><P> </P><P> </P> Tue, 07 Apr 2026 10:20:11 GMT KyeJeong 2026-04-07T10:20:11Z LPSPI3 + eDMA4 Transfer Issue on i.MX93 EVK (M33 Core) https://community.nxp.com/t5/i-MX-Processors/LPSPI3-eDMA4-Transfer-Issue-on-i-MX93-EVK-M33-Core/m-p/2346223#M244795 <P>Hello,</P><P>I am currently testing an external ADC (ADS131E08) functionality using the i.MX93 EVK. I have already confirmed that the LPSPI3 interface works fine in Polling/Interrupt mode. Now, I am trying to implement LPSPI3 combined with eDMA4 to optimize performance.</P><P>Environment:</P><P>Target Board: MCIMX93-EVK (Cortex-M33)</P><P>SDK Version: MCUXpresso SDK 25.12.0</P><P>IDE: VSCode with MCUXpresso Extension</P><P>Since there is no specific "LPSPI-EDMA" example for i.MX93 in the SDK, I implemented the following based on other peripheral examples:</P><P> </P><P>1. Memory Allocation (OCRAM - NonCacheable)</P><P>I placed all DMA-related buffers and handles in the OCRAM section and configured the MPU as Non-Cacheable to avoid coherency issues.</P><P>============================ code ===============================</P><P>/* Linker Script */ MEMORY { m_data (RW) : ORIGIN = 0x20003000, LENGTH = 0x0001B000 m_ocram (RW) : ORIGIN = 0x20480000, LENGTH = 0x00040000 } .noncacheable_section : { . = ALIGN(32); __noncacheable_start__ = .; *(NonCacheable) __noncacheable_end__ = .; } > m_ocram</P><P>/* Variable Definitions */ __attribute__((section("NonCacheable"), aligned(32))) static lpspi_master_edma_handle_t g_lpspi_master_edma_handle; AT_NONCACHEABLE_SECTION_INIT(static edma_handle_t g_lpspi_tx_dma_handle); AT_NONCACHEABLE_SECTION_INIT(static edma_handle_t g_lpspi_rx_dma_handle); __attribute__((section("NonCacheable"), aligned(32))) static uint8_t dummy_tx_data[ADC_SAMPLE_BYTES] = { ... }; __attribute__((section("NonCacheable"), aligned(32))) static uint8_t sample_buf_ping[INTERPOLATION_L][ADC_SAMPLE_BYTES];</P><P>============================ code ===============================</P><P> </P><P>2. Initialization Process</P><P><SPAN>I configured eDMA4, created handles, and linked them to LPSPI3.</SPAN></P><P>============================ code ===============================</P><P>static void LPSPI_Master_DMA_Init(void) { edma_config_t userConfig; EDMA_GetDefaultConfig(&userConfig); EDMA_Init(DMA4, &userConfig); EDMA_CreateHandle(&g_lpspi_tx_dma_handle, DMA4, LPSPI3_TX_DMA_CHANNEL); // CH 12 EDMA_CreateHandle(&g_lpspi_rx_dma_handle, DMA4, LPSPI3_RX_DMA_CHANNEL); // CH 13 EDMA_SetChannelMux(DMA4, LPSPI3_TX_DMA_CHANNEL, kDma4RequestMuxLPSPI3Tx); EDMA_SetChannelMux(DMA4, LPSPI3_RX_DMA_CHANNEL, kDma4RequestMuxLPSPI3Rx); LPSPI_MasterTransferCreateHandleEDMA( LPSPI3, &g_lpspi_master_edma_handle, LPSPI_MasterUserCallback, NULL, &g_lpspi_rx_dma_handle, &g_lpspi_tx_dma_handle); }</P><P>============================ code ===============================</P><P> </P><P>3. SPI Transaction with Address Conversion</P><P>I used MEMORY_ConvertMemoryMapAddress to provide the System Address (Local2DMA) to the eDMA engine.</P><P>============================ code ===============================</P><P>xfer.txData = (uint8_t *)MEMORY_ConvertMemoryMapAddress((uint32_t)dummy_tx_data, kMEMORY_Local2DMA); xfer.rxData = (uint8_t *)MEMORY_ConvertMemoryMapAddress((uint32_t)sample_buf_ping, kMEMORY_Local2DMA); xfer.dataSize = ADC_SAMPLE_BYTES; xfer.configFlags = kLPSPI_MasterPcs0; status_t ret = LPSPI_MasterTransferEDMA(LPSPI3, &g_lpspi_master_edma_handle, &xfer);</P><P>============================ code ===============================</P><P> </P><P>Current Symptoms:</P><P>The first call to LPSPI_MasterTransferEDMA returns kStatus_Success, but no SPI clock or data is observed on the oscilloscope.</P><P>From the second call onwards, it consistently returns kStatus_LPSPI_Busy. This suggests that the driver's internal state is stuck in 'Busy' because the first transfer never completed or triggered the 'Transfer Done' interrupt.</P><P>Checking the eDMA4 registers:</P><P>TCD[12].CH_CSR (ERQ bit) is 0 (or not being set properly).</P><P>CH_ES (Error Status) sometimes shows DBE (Destination Bus Error).</P><P>The LPSPI3 DER register has TDDE and RDDE bits set to 1 after the first call, meaning the SPI peripheral is requesting DMA, but the eDMA engine is not responding.</P><P> </P><P> </P> Tue, 07 Apr 2026 10:20:11 GMT https://community.nxp.com/t5/i-MX-Processors/LPSPI3-eDMA4-Transfer-Issue-on-i-MX93-EVK-M33-Core/m-p/2346223#M244795 KyeJeong 2026-04-07T10:20:11Z Re: LPSPI3 + eDMA4 Transfer Issue on i.MX93 EVK (M33 Core) https://community.nxp.com/t5/i-MX-Processors/LPSPI3-eDMA4-Transfer-Issue-on-i-MX93-EVK-M33-Core/m-p/2346505#M244800 <P>Hi,</P> <P>Thank you for your interest in NXP Semiconductor products,</P> <P>You can confirm that you have adjusted the resource assignment, clocks and eDMA config with the following Cortex-M SDK test.</P> <P><A href="https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Test-LPUART2-DSP-domain-EDMA-on-i-MX8ULP-M33/ta-p/2084403" target="_blank">https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Test-LPUART2-DSP-domain-EDMA-on-i-MX8ULP-M33/ta-p/2084403</A></P> <P>Regards,</P> Tue, 07 Apr 2026 17:38:11 GMT https://community.nxp.com/t5/i-MX-Processors/LPSPI3-eDMA4-Transfer-Issue-on-i-MX93-EVK-M33-Core/m-p/2346505#M244800 JosephAtNXP 2026-04-07T17:38:11Z Re: LPSPI3 + eDMA4 Transfer Issue on i.MX93 EVK (M33 Core) https://community.nxp.com/t5/i-MX-Processors/LPSPI3-eDMA4-Transfer-Issue-on-i-MX93-EVK-M33-Core/m-p/2346633#M244807 Thank you for your quick response.<BR /><BR />As you suggested, I attempted to configure the TRDC to enable DMA access. However, since my M33 firmware is running in Non-Secure mode, any attempt to access or modify the TRDC registers results in a HardFault (Bus Error).<BR /><BR />Based on this, I have a follow-up question:<BR />Is it mandatory to complete the TRDC peripheral/memory access configurations within the A55 U-Boot (or ATF/SPL) phase before launching the M33 core?<BR /><BR />Since the TRDC seems to be locked or restricted for Non-Secure M33 masters, I suspect that the configuration for LPSPI3 and eDMA4 must be pre-defined in the bootloader's TRDC initialization table. Could you confirm if this is the correct architectural approach for i.MX93? Wed, 08 Apr 2026 02:00:07 GMT https://community.nxp.com/t5/i-MX-Processors/LPSPI3-eDMA4-Transfer-Issue-on-i-MX93-EVK-M33-Core/m-p/2346633#M244807 KyeJeong 2026-04-08T02:00:07Z