AM2632: How to configure QSPI&GPMC&UART to EDMA mode

Hello,

Zhang Xun said:

If the actual data length is more than or less than the expected data length in some abnormal situations, how can we identify this situation is happening and cancel this UART transaction or DMA transaction? So, we can try to start the next transaction rather than blocking the rest of all transactions.

(1) To solve abnormal data length situations, we can implement a callback mode with timeout using a three-layer protection mechanism. First, by configuring UART in callback mode, when UART_read() is called, it will return immediately after initiating the DMA transfer without blocking the CPU, allowing the task to continue executing. Second, instead of blocking indefinitely, after the UART_read() is called we can use SemaphoreP_pend() with a timeout parameter (e.g., 1000ms) to wait for the callback to signal completion via semaphore post. If the timeout expires before data arrives (meaning the expected data never came or came partially), the function will return SystemP_TIMEOUT, allowing us to call UART_readCancelNoCB() to abort the stuck transaction and recover to start the next transaction. Third, even when data does arrive within the timeout, we can check gUartReadTrans.count against the expected length to detect partial data scenarios - if only 26 bytes arrive when 29 are expected, this mismatch can be immediately detected, logged, and the application can decide whether to retry, request retransmission, or handle the error gracefully rather than silently using corrupted data. 

Zhang Xun said:

Is there configuration parameter about UART or EDMA time out in SysCfg? If the UART transaction is not happening, how can we identify if the transaction is time out? Besides, I found that the initial time out threshold of semaphore is forever in SDK, can I change this time out value to a reasonable time? And if I configure the UART read&write moede to "Callback", this time out in transaction parameter seems will not be used. So it seems that configuring the time out parameter will be a better way to solve my question.

UART_Transaction.timeout is NOT used in callback mode (as you correctly observed). The UART_read()/UART_write() will return immediately. You must implement timeout using SemaphoreP_pend() with timeout parameter yourself. This is same as needed for implementing (1).

// In callback mode:
int32_t semStatus = SemaphoreP_pend(&gUartBtReadDoneSem, ClockP_usecToTicks(timeoutMs * 1000));

if (semStatus == SystemP_TIMEOUT) {
// Transaction timed out - no data arrived in time

UART_readCancelNoCB(gUartHandle[BT_UART]); // Cancel stuck transaction
// Handle timeout - retry, log error, etc.
}

Regards,

Sahana