iMX8, enabling SDMA on UART1 causes problems

[jaripeltonen]

Hi,

I have a HW that is based on iMX8MP. My SW is based on Yocto project, Kirkstone release, Linux Kernel 5.1.5.60.

I have issues on communicating through UART1. I have noticed that when SDMA is enabled for UART1 in Device Tree (i.e. 'dmas' and 'dma-names' are specified for uart1), timing of data (especially TX data) is different compared to situation where SDMA is disabled for UART1 (i.e. sdma properties are disabled by using 'delete-property'). When SDMA is enabled, the communication between iMX8 and the receiver device that is connected to UART1 is not working properly, especially on baud rates less than 500000.

How can SDMA has this kind of effect on UART communication? Are you aware of this kind of behavior and is there some specific fix that should be applied?

Thanks & best regards,

Jari Peltonen

[ceggers]

Hi Jari,

I would expect the following differences between "PIO" and "DMA" operation:

• For very short transfers, using the (S)DMA may impose extra overhead which could add extra gaps between the transfers.
• For longer transfers, it is likely that (S)DMA may speedup transfers (avoid gaps within the transfers) as the DMA is not affected interrupts / task switches of your operating system.

For further analysis, you may need to provide samples of correct / non-correct TX data.

regards,
Christian

[jaripeltonen]

Hi Christian,

Thanks for your reply!

Please find attached a couple of logic analyzer images.

I have included four different cases (001 - 004);

001: DMA disabled, baud rate 57600

002: DMA enabled, baud rate 57600

004: DMA enabled, baud rate 1M

005: DMA disabled, baud rate 1M

For cases 001 and 002 there are two images, an "overall" image and a more detailed one, named _with_markers.

A few notes regarding the images;
001-NO_DMA_57600_result_OK_with_markers.png vs 002-DMA_57600_result_NOK_with_markers.png
- with DMA enabled, TX pulse width (A1-A2) is 17,208 usec, with DMA disabled it is 17,498 usec
- time periods between TX end and and RX start (C1-C2) are 51,05 usec (DMA enabled) and 50,734 usec (DMA disabled)
- it seems like iMX does not receive (or ignores?) the byte '0x79' (in image 002)

004-DMA_1M_result_OK_with_markers.png vs 005-NO_DMA_1M_result_OK_with_markers.png
- communication works in both cases!
- in both cases, TX and RX pulse widths are 1 usec
- time periods between TX end and and RX start (C1-C2) are 5,54 usec (DMA enabled) vs 4,62 usec (DMA disabled)

What could cause the communication fail at lower baud rates?
According to my tests, communication works ok with baud rates >= 1M.
Can you notice any specific issue in the timings that could explain the problems in communication?

Thanks,

Jari

[ceggers1]

Hi Jari,

for me it sounds unlikely, that the SDMA really effects the bit timing of the UART (in my previous message, I meant the timing between bytes).

1/57600 = 17,361 µs

• DMA enabled: error = |17,361 - 17,208| / 17,361 = 0,88 %
• DMA disabled: error = |17,361 - 17,498| / 17,361 = 0,79 %

The errors in the timing are much less than a UART transmission can tolerate (< 5%). I guess that the timing differences between DMA / non-DMA are caused by limitations in the measurement. I don't think that your problem is caused by differences in the bit timing.

Regarding the missing RX byte please note that the SDMA behaves differently if the SDMA firmware is (not) loaded. Please check the kernel log whether the SDMA firmware could be loaded at startup. On some systems, the firmware is missing in the rootfs.

If I understand the description correctly, the i.MX transmits on the blue channel and receives on the green channel. It seems that the i.MX doesn't recognize the received byte (0x79) and therefore stops transmitting further bytes. Is this correct?

How are the UART of the i.MX and the other system connected to each other? Is it full duplex link ("TTL" or "RS232"), or do you use half-duplex (e.g. RS-485). If you have a half-duplex link, please also record the DE/nRE signal of the transceiver.

regards,
Christian

[jaripeltonen]

Hello Christian,

Yes, you are right, in the pictures, data is transmitted on the blue line and received on the green line.

According to my tests it seems that when having SDMA enabled and using low baud rates (< 500000) there is no data coming in into iMX receiver buffer although the data is visible in the logic analyzer. I have tried different kinds of "tricks", for example adding delays, adding extra reads etc. but it clearly seems that no data is present in the receiver buffer when it should be.

If you look at the picture '002-DMA_57600_result_NOK.png', the reply message (0x79 on green line) is not present in the receiver buffer, and therefore the "handshake" fails.

When using higher baud rates (e.g. 500000, 576000, ..., 1500000), the communication works ok and data is received successfully.

This issue is clearly related to both SDMA and low baud rates; when disabling SDMA, communication on low baud rates work ok.

Has anyone else reported issues regarding SDMA?

Are there some major differences/updates in the SW driver for SDMA in Linux Kernel 5.15.60 (Yocto Kirkstone) compared to Linux Kernel 5.4.70 (Yocto Zeus) and ? On 5.14.70 there were no communication issues on UART1 with SDMA.

Best regards,

Jari

[jaripeltonen]

Hi,

Anyone (NXP experts or community members), please comment on my previous questions!

Thanks,

Jari