Questions about i.MX RT LPUART driver

[Maciek]

I have a few questions regarding LPUART in 'Transfer' mode:

1. If I understand correctly, this driver shares the same issue that was discussed in case of LPI2C and LPSPI drivers in another forum thread:
'Data Rx' output is located in 'Data Transfer' block instead of being an output in 'Transfer Callback' block.
Am I right ? If yes: can we expect a change/improvement in this driver also ?

3. Transfer structure for LPUART driver does not have the 'direction' field: it means that (unlike LPI2C and LPSPI) we can initiate 'read' and 'write' transfers independently (i.e. one can be initiated without waiting for the completion of the other). Both transfers have independent state machines. Am I right ?

4. If I'm right with the above: we have to be able to differentiate between 'read transfer complete' and 'write transfer complete' in the callback function. In toolbox example the distinction is made by reading 'Transfer Status' output of the 'Transfer Callback' block: 1303 means 'read transfer complete' and 1302 means 'write transfer complete'. This output is updated only when the callback is executed. Between callback calls, it shows the status from the last callback execution. Do I understand correctly ?

5. To know on what conditions a particular status code is returned by 'Data Transfer' block it's enough to examine the body of appropriate SDK functions like 'LPUART_TransferSendNonBlocking' etc. Where should I look for returned status codes in the SDK source code for 'Transfer Callback' block? I want to examine the source code to see which status codes are returned and in what situations when the callback subsystem is executed (this question is relevant to all drivers: LPUART, LPSPI and LPI2C - please point me where to find relevant code in SDK).

6. When using 'Transfer Callback' block: we must define 'Transfer callback function name' in Config Tools as 'LPUART_TransferCallback' (other names are not allowed). Am I right ?

Thanks for help
Maciek

[ioanapirjol]

Hi Maciek,

1. Yes, the Data Rx output is associated with the Data Transfer block - we will investigate if this approach works for LPUART and LPSPI as well - for LPUART Transfer from what I tested it should be possible, I will keep you updated on this.

3. From my understanding of the SDK functions, both Read and Write in Transfer LPUART use the same Interrupt Handler (the default SDK implementation is in LPUART_TransferHandleIRQ). My guess (but I could be wrong) would be that even though you have different API functions for send and receive, the logic is similar as in LPI2C: the Transfer functions (Send or Receive) will enable the interrupts and return immediately, and the actual transfer is handled separately by the interrupt routine: so even though you start them without waiting for completion of the other, they will be executed in the order in which the interrupts are detected (I tested with a LPUART_TransferReceiveNonBlocking followed by a LPUART_TransferSendNonBlocking of an array of characters - the transmit sequence was started and at some point disrupted by the detection of a receive interrupt - the final result was the expected one, but honestly I do not know if this approach will work well in more complex scenarios.
A difference that I noticed was that for Receive, if the RX ring buffer is used, the data is read directly in the non-blocking function.

4. Yes, you are right with the Transfer Status output, it will contain the status of the last completed transfer, as returned by the interrupt handler.

5. The SDK uses a macro (MAKE_STATUS) to compute the status codes for each driver, and it is defined in fsl_common.h as :
#define MAKE_STATUS(group, code) ((((group)*100) + (code))),
where "group" is the Status Group Code of the peripheral (all of the peripheral codes are defined in the enum _status_groups in fsl_common.h) and "code" is the error code for each peripheral, defined in the SDK driver headers.
For example, for LPUART, the status group code is given as kStatusGroup_LPUART = 13, and the errors go from 0-15, so some of the status codes would be:
kStatus_LPUART_TxIdle = MAKE_STATUS(kStatusGroup_LPUART, 2) = 13 * 100 + 2 = 1302
kStatus_LPUART_RxIdle = MAKE_STATUS(kStatusGroup_LPUART, 3) = 13 * 100 + 3 = 1303
and so on. You can find the rest of the codes in fsl_lpuart.h (similar for the rest of the drivers). We will update the documentation of the blocks with the exact status codes as well.

To see exactly the context in which each status is returned, you can go look in the Interrupt Handler routine (LPUART_TransferHandleIRQ), and search for the lines of code where "handle->callback" is triggered, the third argument is the status which is returned in the function.

6. You should be allowed to change the default name of the Callback - I tested it now with a new name and it worked fine; the TLC generation script is parameterized to use the name configured by the user in ConfigTools, also the LPUART_TransferCreateHandle is updated with the new name.

Best regards,

Ioana