DMA Engine constraints on S32K148

[periagounder_ar]

Hi,

I am looking for any application note or technical document regarding DMA engine constraints on the S32K148 MCU. 

In our product implementation, we have several high speed communication buses.   Currently we are using 13 out of 16 available DMA channels for moving data from peripherals like LPUART, FlexIO, SPI to SRAM memory.  A lot of these peripherals are being clocked at speeds of 10 to 12 Mbps.

We are seeing receive overrun errors occasionally on some peripherals and would like to understand if it’s related to DMA throughput issue when several DMA channels are active at the same time.

Is there a max throughput of xxx Mbps that the DMA engine can sustain?  Are there any best practices in optimizing the use of the DMA engine?

Thanks

[danielmartynek]

Hi @periagounder_ar,

You can optimize the eDMA operations.

First of all, the eDMA module is a master on the Crossbar switch

danielmartynek_0-1631110806962.png

danielmartynek_1-1631110982942.png

For more information about the crossbar switch arbitration please refer to the RM, Chapter 14
Crossbar Switch Lite (AXBS-Lite).

In the eDMA module, again you can use the default Fixed priority arbitration (default) or the round robin arbitration:

danielmartynek_2-1631111291664.png

If you use fixed priority arbitration, you can assign a priority number to each DMA channel.

danielmartynek_3-1631111417976.png

So the solution could be in setting higher priorities to the channels that fail to trasnfer the data in time. 

Regards,

Daniel

[RomanPBudek]

We need some more information on the DMA.

Some additional notes from discussion with the customer.

1. The fault happens infrequently, about 2 to 3 times per weekend run.
2. DMA parameters are not changed during execution, so that can not be a possible source
3. DMA interrupts are limited in order to comply with the ISO safety requirements
4. Other peripherals running on the DMA function properly with no errors
5. DMA Channel 6 (Flex IO) and DMA Channel 7 (UART) are running at 12Mbps
6. Overrun error is generated
7. Data before and after overrun are fine in memory, but the overrun packet is lost

Some questions from me

1. What is the expected performance of the DMA?
2. Since the issues are with the Flex IO and UART, could this be a problem with the setup of the peripheral rather than just a bandwidth issue?

@danielmartynek @periagounder_ar 

[RomanPBudek]

@danielmartynek @periagounder_ar 

I will check with the customer because according to the chart of interrupts, some of the other TX and RX functions appear to be running faster without any issues. That implies it is not a DMA throughput issue. If I am reading the chart correctly, it implies that the issue is isolated to the peripheral used on DMA Channel 6 and 7 rather than the DMA itself.

[RomanPBudek]

@danielmartynek @periagounder_ar 

I have had lengthy discussions with the customer regarding the setup. When the customer slows down the UARTs, no data is lost through the DMA. When they bring the speed back up the desired 12Mbps, then they get DMA overruns.

The following data is not specified in the datasheet, and the customer would like to know how NXP characterized this data.

We are looking for a paper/explanation from NXP that describes the constraints / considerations for designing with the DMA / communications engines:

1) what is the maximum capacity of the DMA engine?

1a) at max capacity, how much will DMA transfer impact CPU capacity (MIPS)

2) what is the maximum capacity for an individual DMA channel?

3) what considerations are to be made considering each DMA channel’s throughput (Mbps), packet size, update rate, water mark, and channel priority  to have reliable transfer without overruns?

[danielmartynek]

Hi @RomanPBudek,

As I wanted to explain in the initial answer, there are many variables.

Please refer to AN12972 Optimizing the S32K1xx eDMA for Performance Demanding Applications 

https://www.nxp.com/docs/en/application-note/AN12972.pdf

Because of that, I'm afraid we don't have such data.

You can test different crossbar arbitration / DMA arbitration schemes, like assigning a higher priority to the channel used for UART.

Regads,

Daniel

[RomanPBudek]

@danielmartynek 

Thanks for the document. 

I am looking for a document which can be used to calculate the capacity of the DMA. Something which has formulas based on the clock rate. Then I can plug in the customer data to see if we are close to the limits or not.

Thanks,

Roman

[danielmartynek]

Hi Roman,

You can refer to MPC563x RM, Section 7.4.3.

https://www.nxp.com/files-static/32bit/doc/ref_manual/MPC563XMRM.pdf

These equations and estimated "DMA peak request rate" calculated in the RM for the MPC56xx could be also applied to the S32K1. Even though we have a different platform, the DMA module is very similar and the platform architecture is quite similar (one Crossbar bus with one peripheral bridge as a slave). But that equation was formulated in an ideal scenario where there are no interferences from other requests, nor other masters communications on the Crossbar, nor delays by peripherals, so, I'm not sure if this is any help.

It depends on the application-specific scenarios, different factors and we cannot determinate a single max value.

According to the app note, users could check the "time slot request", which is the minimum time needed between one DMA channel request to avoid any possible overrun or underrun, and normally if we don't consider a lot of DMA transfers, this min time is easily accomplished. Now, if we do have overrun issues, then we can only try to optimize the communication transfers. Unfortunately, there isn't much we can do to speed up the DMA and in the end, we cannot limit the customer application with a number of DMA channels / requests / frequency.

A colleague of mine encountered a similar issue, some overrun and underrun UART flags (missing data). The main problem there was that they were using Scatter-Gatter feature (instead of the linking feature) and that they didn't have enabled the FIFO for the LPUART. After they changed it in their application, they didn't experiment with any flag or missing data again.

Maybe you could also verify that you are properly using these features.

Regards,

Daniel