TDA4VM: Using multiple DMA perhiperals issue

Hello Tomislav,

The test code you have written for UDMA is wrong. 

You can refer SPI example in the below path. We have only a single peripheral handling at a single time and don't have any example in MCAL , handling 2 or more peripherals at a time because we don't have AUTOSAR OS at our end. 

Tomislav Zivec said:

• Eth DMA channels 80 and 81
• SPI DMA channels 82 and 83

These are not channels these are interrupt numbers which need to be given in configuration for dmaTxIntrNum and dmaRxIntrNum.

Please go through the TRM documents or data manual on DMA to understand the working of DMA

dev.ti.com/.../data_movement_architecture.html

Regards

Tarun Mukesh

Hello Tarun,

Thank you very much for holding on to specific words, which yeah I mistankenly written in a rush, but still.

Look, so the code is updated yesterday:

And when debugging I get an issue during Spi_Init().

On Spi_DmaInitTxCh return value is -1 and SPI is not getting to SPI_IDLE state.

Can you help debug this?

Best Regards,

Tomislav

BTW. also to be able to debug deeper into Udma I need to build debug udma.aer5f and have an issue there. What kind of modifications are needed in the PSDK to build it:

PS C:\ti\ti-processor-sdk-rtos-j721e-evm-11_01_00_04\pdk_jacinto_11_01_00_17\packages\ti\build> gmake -s BOARD=j721e_evm CORE=mcu1_0 BUILD_PROFILE=debug udma
# Compiling j721e:mcu1_0:debug:udma:src/udma.c
process_begin: CreateProcess(NULL, C:/ti/ti-processor-sdk-rtos-j721e-evm-11_01_00_04/ti-cgt-armllvm_4.0.1.LTS/bin/tiarmclang -MMD -g -DMAKEFILE_BUILD -c -Wall -Wno-extra -Wno-exceptions -ferror-limit=100 -Wno-unused-command-line-argument -Wno-unused-function -Wno-extern-initializer -Wno-excess-initializers -Wno-bitfield-constant-conversion -Wno-address-of-packed-member -fno-strict-aliasing -EL -g -mfloat-abi=hard -mfpu=vfpv3-d16 -mcpu=cortex-r5 -mthumb -march=thumbv7r -Werror -D_DEBUG_=1 -O1 -DBUILD_MCU1_0 -DBUILD_MCU -DUDMA_CFG_ASSERT_ENABLE -DUDMA_CFG_PRINT_ENABLE -DSOC_J721E -IC:/ti/ti-processor-sdk-rtos-j721e-evm-11_01_00_04/pdk_jacinto_11_01_00_17/packages -IC:/ti/ti-processor-sdk-rtos-j721e-evm-11_01_00_04/ti-cgt-armllvm_4.0.1.LTS/include/c -c -x c src/udma.c -o C:/ti/ti-processor-sdk-rtos-j721e-evm-11_01_00_04/pdk_jacinto_11_01_00_17/packages/ti/binary/ti/drv/udma/obj/j721e/mcu1_0/debug/udma.oer5f -MF C:/ti/ti-processor-sdk-rtos-j721e-evm-11_01_00_04/pdk_jacinto_11_01_00_17/packages/ti/binary/ti/drv/udma/obj/j721e/mcu1_0/debug/little/.deps/udma.d, ...) failed.
make (e=2): The system cannot find the file specified.
C:/ti/ti-processor-sdk-rtos-j721e-evm-11_01_00_04/pdk_jacinto_11_01_00_17/packages/ti/build/makerules/rules_ti_cgt_arm.mk:199: recipe for target 'C:/ti/ti-processor-sdk-rtos-j721e-evm-11_01_00_04/pdk_jacinto_11_01_00_17/packages/ti/binary/ti/drv/udma/obj/j721e/mcu1_0/debug/udma.oer5f' failed
gmake[1]: *** [C:/ti/ti-processor-sdk-rtos-j721e-evm-11_01_00_04/pdk_jacinto_11_01_00_17/packages/ti/binary/ti/drv/udma/obj/j721e/mcu1_0/debug/udma.oer5f] Error 2
makefile:328: recipe for target 'udma' failed
gmake: *** [udma] Error 2
PS C:\ti\ti-processor-sdk-rtos-j721e-evm-11_01_00_04\pdk_jacinto_11_01_00_17\packages\ti\build>

Hello Tomislav,

If i understand correctly for SPI DMA channels 82 and 83 without Eth yet , you are getting error. Am i right ? 

Please dig into Spi_DmaInitTxch  where inside it is failing.

Tomislav Zivec said:

BTW. also to be able to debug deeper into Udma I need to build debug udma.aer5f and have an issue there. What kind of modifications are needed in the PSDK to build it:

Based on your error , it is some error in path issue to find the files "The system cannot find the file specified." The tools path and sdk download path is causing the issues . Please check your local paths

The command "pdk_libs" will build all the libraries needed. 

Regards

Tarun Mukesh

Hello Tarun Mukesh,

Today I had some progress, I have used this to setup Eth DMA from DaVinci with this recommended values - https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1373220/faq-tda4vm-how-do-we-avoid-udma-resource-conflict-issues-when-integrating-the-mcal-eth-module-with-other-modules/5244895?tisearch=e2e-sitesearch&keymatch=How%20to%20avoid%20resource%20conflict%20with%20MCAL%20ETH

And here is my code in the Application to initialize Eth DMA and Spi DMA-

However even though this shoudl fix resources allocation conflicts seems it is failing for the Spi.

I get to:

Spi_Init -> Spi_DmaConfig -> Spi_DmaInitTxCh (returns UDMA_SOK)

Spi_Init -> Spi_DmaConfig -> Spi_DmaInitRxCh (returns UDMA_SOK)

Spi_Init -> Spi_DmaConfig ->Spi_DmaRegisterEvent (returns UDMA_EALLOC -8)

Seems that it might be an issue related to Global Event start numbers or? I have changed Eth one to 16900 as suggested, but how do we check and what are the values needed to be set inside mine implementation taken from McspiApp code example?

These are configs for Spi and Eth:

We have a hard deadline from clients side to finish this by EOW. I hope you understand and could support me on resolving this issue.

If you need any more data or we could have a live debug session please let me know.

I suppose also it would be beneficial for TI to have working example for 2 peripherals working together on DMA, currently I don't see such example.

Best Regards,

Tomislav

To be more specific. EALLOC is coming from line 727 in udma_event.c:

Hi,

Tomislav Zivec said:

Seems that it might be an issue related to Global Event start numbers or? I have changed Eth one to 16900 as suggested, but how do we check and what are the values needed to be set inside mine implementation taken from McspiApp code example?

The mapping of resources to core is based on BoardCfg information, can be found from j721e_evm.syscfg file.


if you are using default Board configuration from TI, 16900 suppose to work.

From code and sequence, and the failure mentioned, I hope you are not facing any allocation issue from Eth.

Tomislav Zivec said:

I suppose also it would be beneficial for TI to have working example for 2 peripherals working together on DMA, currently I don't see such example.

As mentioned by Tarun above, we don't have AUTOSAR OS validate multiple applications and drivers together.
To avoid resource conflict when integrating Eth with other modules using DMA resources, we have created an FAQ for customers to manage resources.
[FAQ] TDA4VM: How do we avoid UDMA resource conflict issues when integrating the MCAL Eth module with other modules?
Above FAQ, resolved resource conflict issue observed many customers. We are expecting in your case also it should work if you are using default Board configuration from TI SDK.

Can you please Initialize the SPI DMA before Eth and check whether you are facing any issue with UDMA resources allocation?


Best Regards,
Sudheer

Hello Sudheer,

We are using default BoardCfg, however devn though I applied the fix mentined on that link which we both shared it isn ot working.

2 scenarios:

1. Eth DMA initialized before Spi DMA from the code I showed you.

Result:

In Udma_eventAllocResource EALLOC occurs because of eventHandle->coreIntrNum

Please find the eventHandle values on the top right. Acutally globalEvent seems fine, vintrNum also, however coreIntrNum is INVALID. 

Do you know what could be the reason?

2. Spi DMA initilaized before Eth DMA

Seems that eventHandle values in the Spi DMA initialization look the same and also I get EALLOC (-8).

Code is stuck in DET_EndlessLoop because of it again.

So in both scenarios it is working the same, seems like something wrong with Spi setup, config or whatever. How we can adjust this coreIntrNum?

Best Regards,

Tomislav

Hello Tomislav,

Try using 79 and 80 IntrNum for SPI.

Regards

Tarun Mukesh

Hello Tarun, I have tried but same thing happen. Any other ideas we can try out?

Hello Tomislav,

Tomislav Zivec said:

Spi DMA initilaized before Eth DMA

I will test on the TI EVM with single example of SPI  with DMA for 79 and 80 and will let you know the status .

Regards

Tarun Mukesh

Do you see any benefit if I send you binary of my solution over mail so you can debug on your sid?. Maybe you get more clarity.

Hello Tarun,

I am hitting a breakpoint for Udma_eventRegister even before I reach Spi_Init. And seems we are assigning IntrNum 80 there.

Do you know where it is coming from?

Maybe that is a problem because we try to reuse it later, or?

Here it fails 79, or 80 is not less then (16+11)

Hello Tomislav,

Tomislav Zivec said:

Here it fails 79, or 80 is not less then (16+11)

Is it failing here ?

79 and 80 are coreIntrNum not IrIntNum. what is preferredIrIntrNum here in this case ?

80 is valid number to use.

Regards

Tarun Mukesh

Seems actually other condition fails -> not >=16

I can see on function entry preferredIrIntrNum is 15.

But when stepping through the fuunction to condition I don't see it anymore in Variables. Not sure if it is some debugger limitation or what.

Did you have any success on running on your own side Spi DMA example?

just a note: we are using SD_CARD boot if it matters because of that CSL call.

Hello Tarun, I have set numbers 81 and 82 and it passes now, SPI is in SPI_IDLE state, seems 80 is taken by something else.

However in this case either when Eth is first or vice versa to initialize EthTrcv link is not getting up with the same code.

If I remove Spi_Initialization (comment it out) then Eth is getting Link. What could there be an issue...?

Hi,

Tomislav Zivec said:

Hello Tarun, I have set numbers 81 and 82 and it passes now, SPI is in SPI_IDLE state, seems 80 is taken by something else.

Thanks for letting know, your resources issue was resolved with above interrupt mapping to SPI.

Tomislav Zivec said:

If I remove Spi_Initialization (comment it out) then Eth is getting Link. What could there be an issue...?

There is nothing related to SPI and Ethernet Trcv (driver related to Ethernet PHY), until if you are any SPI pins as GPIO for PHY reset.

Best Regards,
Sudheer

Well with the same PIN configs I was able to run if without DMA some time ago with old SDK.

Doredla Sudheer Kumar said:

until if you are any SPI pins as GPIO for PHY reset.

Can you clarify what exactly you mean with this?

this is my setup:

void Spi_PlatformInit(void)
{
    uint32 regVal;
    /* write Partition Lock Key 0 Register */
    CSL_REG32_WR(CSL_MCU_CTRL_MMR0_CFG0_BASE + CSL_MCU_CTRL_MMR_CFG0_LOCK1_KICK0, MMR_KICK0_UNLOCK_VAL);
    /* write Partition Lock Key 1 Register */
    CSL_REG32_WR(CSL_MCU_CTRL_MMR0_CFG0_BASE + CSL_MCU_CTRL_MMR_CFG0_LOCK1_KICK1,MMR_KICK1_UNLOCK_VAL);
    /* Check for unlock */
    regVal = CSL_REG32_RD(CSL_MCU_CTRL_MMR0_CFG0_BASE + CSL_MCU_CTRL_MMR_CFG0_LOCK1_KICK0);
    while ((regVal & 0x1U) != 0x1U)
    {
        regVal = CSL_REG32_RD(CSL_MCU_CTRL_MMR0_CFG0_BASE + CSL_MCU_CTRL_MMR_CFG0_LOCK1_KICK0);
    }
    /* Unlock lock key registers for Partition 7: IO PAD
      configuration registers in MAIN_CTRL_MMR */
    /* write Partition 7 Lock Key 0 Register */
    CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_LOCK7_KICK0, MMR_KICK0_UNLOCK_VAL);
    /* write Partition 7 Lock Key 1 Register */
    CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_LOCK7_KICK1, MMR_KICK1_UNLOCK_VAL);
    /* Check for unlock */
    regVal = CSL_REG32_RD(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_LOCK7_KICK0);
    while ((regVal & 0x1) != 0x1U)
    {
		regVal = CSL_REG32_RD(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_LOCK7_KICK0);
    }
  /* GPIO_MICX_RESB -> GPIO0_52 -> AB26 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG53, PIN_MODE(7U) | PIN_OUTPUT);

  /* GPIO_MIC1_CSB -> GPIO0_10 -> AG2025 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG10, PIN_MODE(7U) | PIN_OUTPUT);

  /* GPIO_MIC1_RFC -> GPIO0_81 -> AA26 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG82, PIN_MODE(7U) | PIN_INPUT);

  /* GPIO_MIC1_INTB -> GPIO0_82 -> AA29 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG83, PIN_MODE(7U) | PIN_INPUT);

  /* GPIO_MIC1_DAB -> GPIO0_84 -> AA27 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG85, PIN_MODE(7U) | PIN_INPUT);

  /* GPIO_MIC1_BFWB -> GPIO0_83 -> Y26 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG84, PIN_MODE(7U) | PIN_INPUT);

  /* GPIO_MIC2_CSB -> GPIO0_11 -> AD21 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG11, PIN_MODE(7U) | PIN_OUTPUT);

  /* GPIO_MIC2_RFC -> GPIO0_30 -> AF21 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG31, PIN_MODE(7U) | PIN_INPUT);

  /* GPIO_MIC2_INTB -> GPIO0_31 -> AB23 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG32, PIN_MODE(7U) | PIN_INPUT);

  /* GPIO_MIC2_DAB -> GPIO0_6 -> AD20 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG6, PIN_MODE(7U) | PIN_INPUT);

  /* GPIO_MIC2_BFWB -> GPIO0_80 -> Y25 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG81, PIN_MODE(7U) | PIN_INPUT);

  /* GPIO_CFG1 -> GPIO0_48 -> AC29 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG49, PIN_MODE(7U) | PIN_OUTPUT);

  /* SPI6_CLK -> GPIO0_38 -> AC22 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG39, PIN_MODE(4U) | PIN_OUTPUT);

  /* SPI6_D0 -> GPIO0_39 -> AJ22 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG40, PIN_MODE(4U) | PIN_OUTPUT);

  /* API6_D1 -> GPIO0_40 -> AH22 (DRA721E) */
  CSL_REG32_WR(CSL_CTRL_MMR0_CFG0_BASE + CSL_MAIN_CTRL_MMR_CFG0_PADCONFIG41, PIN_MODE(4U) | PIN_INPUT);
}

void Spi_SetGpioDirections(void)
{
  /* Set GPIO0_52 direction to output */
  GPIOSetDirMode_v0(CSL_GPIO0_BASE, 52U, GPIO_DIRECTION_OUTPUT);

  /* Set GPIO0_10 direction to output */
  GPIOSetDirMode_v0(CSL_GPIO0_BASE, 10U, GPIO_DIRECTION_OUTPUT);

  /* Set GPIO0_81 direction to input */
  GPIOSetDirMode_v0(CSL_GPIO0_BASE, 81U, GPIO_DIRECTION_INPUT);

  /* Set GPIO0_82 direction to input */
  GPIOSetDirMode_v0(CSL_GPIO0_BASE, 82U, GPIO_DIRECTION_INPUT);

  /* Set GPIO0_84 direction to input */
  GPIOSetDirMode_v0(CSL_GPIO0_BASE, 84U, GPIO_DIRECTION_INPUT);

  /* Set GPIO0_83 direction to input */
  GPIOSetDirMode_v0(CSL_GPIO0_BASE, 83U, GPIO_DIRECTION_INPUT);

  /* Set GPIO0_11 direction to output */
  GPIOSetDirMode_v0(CSL_GPIO0_BASE, 11U, GPIO_DIRECTION_OUTPUT);

  /* Set GPIO0_30 direction to input */
  GPIOSetDirMode_v0(CSL_GPIO0_BASE, 30U, GPIO_DIRECTION_INPUT);

  /* Set GPIO0_31 direction to input */
  GPIOSetDirMode_v0(CSL_GPIO0_BASE, 31U, GPIO_DIRECTION_INPUT);

  /* Set GPIO0_6 direction to input */
  GPIOSetDirMode_v0(CSL_GPIO0_BASE, 6U, GPIO_DIRECTION_INPUT);

  /* Set GPIO0_80 direction to input */
  GPIOSetDirMode_v0(CSL_GPIO0_BASE, 80U, GPIO_DIRECTION_INPUT);

  /* Set GPIO0_48 direction to output */
  GPIOSetDirMode_v0(CSL_GPIO0_BASE, 48U, GPIO_DIRECTION_OUTPUT);
  /* Set GPIO0_48 level to HIGH */
  GPIOPinWrite_v0(CSL_GPIO0_BASE, 48U, GPIO_PIN_HIGH);
}

Do you recongnize any of this pins to be related to PHY RESET?

Tarun Mukesh Puvvada  kind reminder on Spi tryout on your side. Do you have Spi Tx and Rx working normally?

Best Regards,

Tomislav

Hello Tomislav,

Tomislav Zivec said:

Hello Tarun, I have set numbers 81 and 82 and it passes now, SPI is in SPI_IDLE state, seems 80 is taken by something else.

I am able to run SPI alone with DMA and no problems it is working normally. I have attached log below

Doredla Sudheer Kumar said:

Thanks for letting know, your resources issue was resolved with above interrupt mapping to SPI.

As sudheer, it is no longer SPI issue related to DMA resources. since it is not failing in DMA initialisation phase.

SPI_APP: SPI + DMA mode used !!!
SPI_APP: Building Interrupt List !!!
SPI_APP: Variant - Post Build being used !!!
SPI_APP: Interrupt List Completed !!!
SPI_APP: Sample Application - STARTS !!!
 
SPI MCAL Version Info
---------------------
Vendor ID           : 44
Module ID           : 83
SW Major Version    : 9
SW Minor Version    : 2
SW Patch Version    : 1
 
SPI_APP: CH 1: JOBS 1: SEQ 1: Max HWUNIT 1: NUM OF WORDS 10000:!!!
SPI_APP: SPI Async transmit in progress!!                                       
SPI_APP: SPI Hwunit 0 configuration Register Readback values                    
SPI_APP: MCSPI_HL_REV                   : 0x40301a0b                            
SPI_APP: MCSPI_HL_HWINFO                : 0x9                                   
SPI_APP: MCSPI_HL_SYSCONFIG             : 0x4                                   
SPI_APP: MCSPI_REVISION                         : 0x2b                          
SPI_APP: MCSPI_SYSSTATUS                : 0x1                                   
SPI_APP: MCSPI_SYST                     : 0x0                                   
SPI_APP: MCSPI_MODULCTRL                : 0x1                                   
SPI_APP: MCSPI_SYSCONFIG                : 0x308                                 
SPI_APP: MCSPI_CH0CONF                  : 0x20050f80                            
SPI_APP: MCSPI_CH1CONF                  : 0x60000                               
SPI_APP: MCSPI_CH2CONF                  : 0x60000                               
SPI_APP: MCSPI_CH3CONF                  : 0x60000                               
SPI_APP: MCSPI_IRQENABLE                : 0x0                                   
SPI_APP: McSPI data chIndex:0,length:10000!!                                    
SPI_APP: SPI Stack Usage: 5636 bytes                                            
SPI_APP: All tests have passed!!!

Tomislav Zivec said:

Well with the same PIN configs I was able to run if without DMA some time ago with old SDK.

If you run latest SDK without SPI + DMA , only SPI and Eth with DMA is it running fine ?

Regards

Tarun Mukesh

Hello Tarun,

I have tryed to test only the Spi without Eth even and without DMA. I got into a lot of problems in StartApplication stack overfilling, I increased it even to 64kB and still not enough. Quite strange. But transmission and reception interrupts are happening untill stack gets overfilled.

On the other hand just SPI with DMA (no Eth) we get into Os_UNhandled exception because somewhere after DmaTx interrupt is ocmpletely serviced when we are trying to resume all interrupts and restore ocntext we try to read value from addres 0x6000_01DF + 0x14 which is not valid. Misaligned. And obviously we don't expect anything in that memory area.

After DmaTx ISR is serviced, we get into your code Udma_ringaccMemOps -> CacheP_wb (CacheP_Inv) and for there it jumps to Os_ThreadGetCore and fails raising exception 0x10 as mentioned. I am not sure I woudl expect after this functions to jump there. And because of the Thread pointer passed in as parameter most likely it is some trash data causing this issue because it is not intentional jump.

Could it be that some of the memory areas are overlapping with what we load from SD_Card and also our application with inclusion of TI .aer5f files?

Do you have time time to check with me in a call perhaps you see something I don't since you don't have access to my workspace?

I could send you binary if you could test on your side the behavior?

PS. can you send me binary which you builded for McSpiApp and confirmed it is working over mail?

Best Regards,

Tomislav

Hello Tomislav,

It appears you are facing severe memory critical issues.

I am not sure how the baremetal example binary will help for you, please find the below zip of binary of SPI app which is working at our end. 

mcspi_app.zip

Regards

Tarun Mukesh

Hello Tarun,

Thank you for sending the .zip file. The reason I requested it to try it out and remove the HW related problems, if they exist.

I agree that it seems to be a memory corruption issue (on stacks).

On our side with Vector when debugging we observe the address we are reading from 0x6000_00DF + 0x14 later (which is misaligned) here:

and when I was thinking about and trying to understand in code there is this comment for the push64 function:

 *  This function can only be used when the calling processor is able to issue
 *  a 64-bit burst. If using a 32-bit processor, you should avoid using this
 *  function and instead use the proxy to read/write from/to rings.

Hello Tomislav,

I didn't understand what you are trying to convey here . CSL level API'S have nothing to do here, we are able to use the same driver effectively and also many other customers .

The problem is in your memory configurations of using it cacheable or Non cacheble and those properties. UDMA driver uses cache , so cache operations need to be performed we have done it sample example which can be referred.

Regards

Tarun MUkesh