TDA2HG: MCSPI EDMA RX enable but RX FIFO still full

Tim,

I noticed some irregularities in register fields related to IDLE mode.  From your table, I looked up the following register/value combination in the TRM:

| 0x48098110    | 0x00000318 |

See "Table 24-305 MCSPI_SYSCONFIG."  The register field SIDLEMODE has a reset value of 0x2.  It looks like you have it set to 0x3, which is a reserved value.  Are you unintentionally setting a a bit in this field somewhere?  If you change that and it doesn't fix the problem, you could try setting IDLEMODE field to 0x1, "No-Idle mode."  Currently, it is set to 0x3, which allows it to go into IDLE mode.  However, the ENAWAKEUP field is 0.  The WKEN field is also 0.  Both must be set to 1 in slave mode for the device to wake up when the CS goes active.

-Zack

Hi Zack,

Thanks for reply!

I set SIDLEMODE as 0x2:

root@dra7xx-evm:~# omapconf dump 0x48098000 0x480981A0
|----------------------------|
| Address (hex) | Data (hex) |
|----------------------------|
| 0x48098000    | 0x4030120B |
| 0x48098004    | 0x00000011 |
| 0x48098008    | 0x00000000 |
| 0x4809800C    | 0x00000000 |
| 0x48098010    | 0x00000008 |
| 0x48098014    | 0x00000000 |
| 0x48098018    | 0x00000000 |
| 0x4809801C    | 0x00000000 |
| 0x48098020    | 0x00000000 |
| 0x48098024    | 0x00000000 |
| 0x48098028    | 0x00000000 |
| 0x4809802C    | 0x00000000 |
| 0x48098030    | 0x00000000 |
| 0x48098034    | 0x00000000 |
| 0x48098038    | 0x00000000 |
| 0x4809803C    | 0x00000000 |
| 0x48098040    | 0x00000000 |
| 0x48098044    | 0x00000000 |
| 0x48098048    | 0x00000000 |
| 0x4809804C    | 0x00000000 |
| 0x48098050    | 0x00000000 |
| 0x48098054    | 0x00000000 |
| 0x48098058    | 0x00000000 |
| 0x4809805C    | 0x00000000 |
| 0x48098060    | 0x00000000 |
| 0x48098064    | 0x00000000 |
| 0x48098068    | 0x00000000 |
| 0x4809806C    | 0x00000000 |
| 0x48098070    | 0x00000000 |
| 0x48098074    | 0x00000000 |
| 0x48098078    | 0x00000000 |
| 0x4809807C    | 0x00000000 |
| 0x48098080    | 0x00000000 |
| 0x48098084    | 0x00000000 |
| 0x48098088    | 0x00000000 |
| 0x4809808C    | 0x00000000 |
| 0x48098090    | 0x00000000 |
| 0x48098094    | 0x00000000 |
| 0x48098098    | 0x00000000 |
| 0x4809809C    | 0x00000000 |
| 0x480980A0    | 0x00000000 |
| 0x480980A4    | 0x00000000 |
| 0x480980A8    | 0x00000000 |
| 0x480980AC    | 0x00000000 |
| 0x480980B0    | 0x00000000 |
| 0x480980B4    | 0x00000000 |
| 0x480980B8    | 0x00000000 |
| 0x480980BC    | 0x00000000 |
| 0x480980C0    | 0x00000000 |
| 0x480980C4    | 0x00000000 |
| 0x480980C8    | 0x00000000 |
| 0x480980CC    | 0x00000000 |
| 0x480980D0    | 0x00000000 |
| 0x480980D4    | 0x00000000 |
| 0x480980D8    | 0x00000000 |
| 0x480980DC    | 0x00000000 |
| 0x480980E0    | 0x00000000 |
| 0x480980E4    | 0x00000000 |
| 0x480980E8    | 0x00000000 |
| 0x480980EC    | 0x00000000 |
| 0x480980F0    | 0x00000000 |
| 0x480980F4    | 0x00000000 |
| 0x480980F8    | 0x00000000 |
| 0x480980FC    | 0x00000000 |
| 0x48098100    | 0x0000002B |
| 0x48098104    | 0x00000000 |
| 0x48098108    | 0x00000000 |
| 0x4809810C    | 0x00000000 |
| 0x48098110    | 0x00000314 |
| 0x48098114    | 0x00000001 |
| 0x48098118    | 0x0003000A |
| 0x4809811C    | 0x00000000 |
| 0x48098120    | 0x00000001 |
| 0x48098124    | 0x00000000 |
| 0x48098128    | 0x00000004 |
| 0x4809812C    | 0x1801C3C0 |
| 0x48098130    | 0x0000004F |
| 0x48098134    | 0x00000001 |
| 0x48098138    | 0x00000000 |
| 0x4809813C    | 0x000000FC |
| 0x48098140    | 0x00060000 |
| 0x48098144    | 0x00000000 |
| 0x48098148    | 0x00000000 |
| 0x4809814C    | 0x00000000 |
| 0x48098150    | 0x00000000 |
| 0x48098154    | 0x00060000 |
| 0x48098158    | 0x00000000 |
| 0x4809815C    | 0x00000000 |
| 0x48098160    | 0x00000000 |
| 0x48098164    | 0x00000000 |
| 0x48098168    | 0x00060000 |
| 0x4809816C    | 0x00000000 |
| 0x48098170    | 0x00000000 |
| 0x48098174    | 0x00000000 |
| 0x48098178    | 0x00000000 |
| 0x4809817C    | 0x00001F1F |
| 0x48098180    | 0x00000000 |
| 0x48098184    | 0x00000000 |
| 0x48098188    | 0x00000000 |
| 0x4809818C    | 0x00000000 |
| 0x48098190    | 0x00000000 |
| 0x48098194    | 0x00000000 |
| 0x48098198    | 0x00000000 |
| 0x4809819C    | 0x00000000 |
| 0x480981A0    | 0x00000000 |
|----------------------------|

And set it as 0x1:

|----------------------------|
| Address (hex) | Data (hex) |
|----------------------------|
| 0x48098000    | 0x4030120B |
| 0x48098004    | 0x00000011 |
| 0x48098008    | 0x00000000 |
| 0x4809800C    | 0x00000000 |
| 0x48098010    | 0x00000004 |
| 0x48098014    | 0x00000000 |
| 0x48098018    | 0x00000000 |
| 0x4809801C    | 0x00000000 |
| 0x48098020    | 0x00000000 |
| 0x48098024    | 0x00000000 |
| 0x48098028    | 0x00000000 |
| 0x4809802C    | 0x00000000 |
| 0x48098030    | 0x00000000 |
| 0x48098034    | 0x00000000 |
| 0x48098038    | 0x00000000 |
| 0x4809803C    | 0x00000000 |
| 0x48098040    | 0x00000000 |
| 0x48098044    | 0x00000000 |
| 0x48098048    | 0x00000000 |
| 0x4809804C    | 0x00000000 |
| 0x48098050    | 0x00000000 |
| 0x48098054    | 0x00000000 |
| 0x48098058    | 0x00000000 |
| 0x4809805C    | 0x00000000 |
| 0x48098060    | 0x00000000 |
| 0x48098064    | 0x00000000 |
| 0x48098068    | 0x00000000 |
| 0x4809806C    | 0x00000000 |
| 0x48098070    | 0x00000000 |
| 0x48098074    | 0x00000000 |
| 0x48098078    | 0x00000000 |
| 0x4809807C    | 0x00000000 |
| 0x48098080    | 0x00000000 |
| 0x48098084    | 0x00000000 |
| 0x48098088    | 0x00000000 |
| 0x4809808C    | 0x00000000 |
| 0x48098090    | 0x00000000 |
| 0x48098094    | 0x00000000 |
| 0x48098098    | 0x00000000 |
| 0x4809809C    | 0x00000000 |
| 0x480980A0    | 0x00000000 |
| 0x480980A4    | 0x00000000 |
| 0x480980A8    | 0x00000000 |
| 0x480980AC    | 0x00000000 |
| 0x480980B0    | 0x00000000 |
| 0x480980B4    | 0x00000000 |
| 0x480980B8    | 0x00000000 |
| 0x480980BC    | 0x00000000 |
| 0x480980C0    | 0x00000000 |
| 0x480980C4    | 0x00000000 |
| 0x480980C8    | 0x00000000 |
| 0x480980CC    | 0x00000000 |
| 0x480980D0    | 0x00000000 |
| 0x480980D4    | 0x00000000 |
| 0x480980D8    | 0x00000000 |
| 0x480980DC    | 0x00000000 |
| 0x480980E0    | 0x00000000 |
| 0x480980E4    | 0x00000000 |
| 0x480980E8    | 0x00000000 |
| 0x480980EC    | 0x00000000 |
| 0x480980F0    | 0x00000000 |
| 0x480980F4    | 0x00000000 |
| 0x480980F8    | 0x00000000 |
| 0x480980FC    | 0x00000000 |
| 0x48098100    | 0x0000002B |
| 0x48098104    | 0x00000000 |
| 0x48098108    | 0x00000000 |
| 0x4809810C    | 0x00000000 |
| 0x48098110    | 0x0000030C |
| 0x48098114    | 0x00000001 |
| 0x48098118    | 0x0003000A |
| 0x4809811C    | 0x00000000 |
| 0x48098120    | 0x00000001 |
| 0x48098124    | 0x00000000 |
| 0x48098128    | 0x00000004 |
| 0x4809812C    | 0x1801C3C0 |
| 0x48098130    | 0x0000004F |
| 0x48098134    | 0x00000001 |
| 0x48098138    | 0x00000000 |
| 0x4809813C    | 0x00000000 |
| 0x48098140    | 0x00060000 |
| 0x48098144    | 0x00000000 |
| 0x48098148    | 0x00000000 |
| 0x4809814C    | 0x00000000 |
| 0x48098150    | 0x00000000 |
| 0x48098154    | 0x00060000 |
| 0x48098158    | 0x00000000 |
| 0x4809815C    | 0x00000000 |
| 0x48098160    | 0x00000000 |
| 0x48098164    | 0x00000000 |
| 0x48098168    | 0x00060000 |
| 0x4809816C    | 0x00000000 |
| 0x48098170    | 0x00000000 |
| 0x48098174    | 0x00000000 |
| 0x48098178    | 0x00000000 |
| 0x4809817C    | 0x00001F1F |
| 0x48098180    | 0x00000000 |
| 0x48098184    | 0x00000000 |
| 0x48098188    | 0x00000000 |
| 0x4809818C    | 0x00000000 |
| 0x48098190    | 0x00000000 |
| 0x48098194    | 0x00000000 |
| 0x48098198    | 0x00000000 |
| 0x4809819C    | 0x00000000 |
| 0x480981A0    | 0x00000000 |
|----------------------------|

And I also change ENAWAKEUP and WKEN as 1, but the problem still.

Hi Zack, Is it possible that edma some registers configure error will cause this problem? If yes, would you please tell me what registers should I dump to investigate? Thanks a lot

Tim,

There doesn't seem to be anything wrong with your MCSPI setup.  So it is possibly EDMA setup, or DMA Crossbar setup, yes.  The EDMA instance summary can be found at "Table 16-108 EDMA Instance Summary in the TRM."  You could dump the registers corresponding to the EDMA you are using.

Hi Zack,

Can I copy "pdk_01_10_04_05/packages/ti/csl/example/mcspi/mcspiMasterSlave/mcspiMasterSlave_spi1_spi2.c" code to my IPU1_0 RTOS task to make it run? Will it conflict with other init?

Just now, I use edma3_lld API to init, but I'm not sure if it is good method.

Thanks!

Hi Zack,

I dump some registers which I think should have corresponding to this issue:

root@dra7xx-evm:~# devmem2 0x43301024 (enable)
/dev/mem opened.
Memory mapped at address 0xb6f4e000.
Read at address  0x43301024 (0xb6f4e024): 0x0000000C

root@dra7xx-evm:~# devmem2 0x43305000 (0x43304000 + (128 * 32))) (PRAMset)
/dev/mem opened.
Memory mapped at address 0xb6f9f000.
Read at address  0x43305000 (0xb6f9f000): 0x80123004

root@dra7xx-evm:~# devmem2 0x4330226C (interrupt pending)
/dev/mem opened.
Memory mapped at address 0xb6ff4000.
Read at address  0x4330226C (0xb6ff426c): 0x00000000

root@dra7xx-evm:~# devmem2 0x4A002CBC (crossbar)
/dev/mem opened.
Memory mapped at address 0xb6f5b000.
Read at address  0x4A002CBC (0xb6f5bcbc): 0x00240023

From this registers value, I can't see any problem, but I'm not sure if it is enough. If you found this value have problem or I missed some registers, please let me know.

Thanks!

Hi Zack Is there any update? Thanks!

Tim,

As I said, there doesn't appear to be anything wrong with your SPI setup.  As for this:

"pdk_01_10_04_05/packages/ti/csl/example/mcspi/mcspiMasterSlave/mcspiMasterSlave_spi1_spi2.c"

Does this example set up the SPI in slave mode with EDMA?  If so, you could try running that example, confirming that it works, and then dump the SPI registers so that we can compare them to your first register dump.  I want to completely rule out SPI as the source of the error.

-Zack

Hi Zack, I can run that example now, but since my board didn’t connect mcspi1 to mcspi2 so only I guess it works fine. But now I have no idea which register should I dump? What I dumped before is not enough? I still don’t know what register configuration can make this problem. I agree it should rule out SPI as the source of the error. But EDMA part of configuration is more complicated for me. So I hope someone can guide me like what you did on SPI This problem really block our product release for a long time. Thanks for your help

But now I have no idea which register should I dump?

If you have an example program that initializes the SPI channel with EDMA transfers, dump the MCSPI registers after running that.

What I dumped before is not enough?

Was the MCSPI register dump in your first post done after running an example program, or after running code you wrote yourself?

I still don’t know what register configuration can make this problem.

The most likely candidates are  the MCSPI registers, the EDMA registers, or the DMA crossbar registers.

If you have an example program that initializes the SPI channel with EDMA transfers, dump the MCSPI registers after running that.

Actually I mean which EDMA register should I dump. What I dumped before (both of those two of my post) is initializes the SPI channel with EDMA transfers and it is wrote by myself.

But since you think run "mcspiMasterSlave_spi1_spi2.c" example is better, so I run that example again and dump register below. As I said before, my board not connect mcspi1 and mcspi2 together, so I must change mcspi1 as slave and ignore mcspi2. Anyway, nothing else had I changed. 

|----------------------------|
| Address (hex) | Data (hex) |
|----------------------------|
| 0x48098000    | 0x4030120B |
| 0x48098004    | 0x00000011 |
| 0x48098008    | 0x00000000 |
| 0x4809800C    | 0x00000000 |
| 0x48098010    | 0x00000004 |
| 0x48098014    | 0x00000000 |
| 0x48098018    | 0x00000000 |
| 0x4809801C    | 0x00000000 |
| 0x48098020    | 0x00000000 |
| 0x48098024    | 0x00000000 |
| 0x48098028    | 0x00000000 |
| 0x4809802C    | 0x00000000 |
| 0x48098030    | 0x00000000 |
| 0x48098034    | 0x00000000 |
| 0x48098038    | 0x00000000 |
| 0x4809803C    | 0x00000000 |
| 0x48098040    | 0x00000000 |
| 0x48098044    | 0x00000000 |
| 0x48098048    | 0x00000000 |
| 0x4809804C    | 0x00000000 |
| 0x48098050    | 0x00000000 |
| 0x48098054    | 0x00000000 |
| 0x48098058    | 0x00000000 |
| 0x4809805C    | 0x00000000 |
| 0x48098060    | 0x00000000 |
| 0x48098064    | 0x00000000 |
| 0x48098068    | 0x00000000 |
| 0x4809806C    | 0x00000000 |
| 0x48098070    | 0x00000000 |
| 0x48098074    | 0x00000000 |
| 0x48098078    | 0x00000000 |
| 0x4809807C    | 0x00000000 |
| 0x48098080    | 0x00000000 |
| 0x48098084    | 0x00000000 |
| 0x48098088    | 0x00000000 |
| 0x4809808C    | 0x00000000 |
| 0x48098090    | 0x00000000 |
| 0x48098094    | 0x00000000 |
| 0x48098098    | 0x00000000 |
| 0x4809809C    | 0x00000000 |
| 0x480980A0    | 0x00000000 |
| 0x480980A4    | 0x00000000 |
| 0x480980A8    | 0x00000000 |
| 0x480980AC    | 0x00000000 |
| 0x480980B0    | 0x00000000 |
| 0x480980B4    | 0x00000000 |
| 0x480980B8    | 0x00000000 |
| 0x480980BC    | 0x00000000 |
| 0x480980C0    | 0x00000000 |
| 0x480980C4    | 0x00000000 |
| 0x480980C8    | 0x00000000 |
| 0x480980CC    | 0x00000000 |
| 0x480980D0    | 0x00000000 |
| 0x480980D4    | 0x00000000 |
| 0x480980D8    | 0x00000000 |
| 0x480980DC    | 0x00000000 |
| 0x480980E0    | 0x00000000 |
| 0x480980E4    | 0x00000000 |
| 0x480980E8    | 0x00000000 |
| 0x480980EC    | 0x00000000 |
| 0x480980F0    | 0x00000000 |
| 0x480980F4    | 0x00000000 |
| 0x480980F8    | 0x00000000 |
| 0x480980FC    | 0x00000000 |
| 0x48098100    | 0x0000002B |
| 0x48098104    | 0x00000000 |
| 0x48098108    | 0x00000000 |
| 0x4809810C    | 0x00000000 |
| 0x48098110    | 0x00000308 |
| 0x48098114    | 0x00000001 |
| 0x48098118    | 0x0003000A |
| 0x4809811C    | 0x00000000 |
| 0x48098120    | 0x00000000 |
| 0x48098124    | 0x00000000 |
| 0x48098128    | 0x00000004 |
| 0x4809812C    | 0x1811C3C0 |
| 0x48098130    | 0x0000004F |
| 0x48098134    | 0x00000001 |
| 0x48098138    | 0x00000000 |
| 0x4809813C    | 0x00000000 |
| 0x48098140    | 0x00060000 |
| 0x48098144    | 0x00000000 |
| 0x48098148    | 0x00000000 |
| 0x4809814C    | 0x00000000 |
| 0x48098150    | 0x00000000 |
| 0x48098154    | 0x00060000 |
| 0x48098158    | 0x00000000 |
| 0x4809815C    | 0x00000000 |
| 0x48098160    | 0x00000000 |
| 0x48098164    | 0x00000000 |
| 0x48098168    | 0x00060000 |
| 0x4809816C    | 0x00000000 |
| 0x48098170    | 0x00000000 |
| 0x48098174    | 0x00000000 |
| 0x48098178    | 0x00000000 |
| 0x4809817C    | 0x00000000 |
| 0x48098180    | 0x00000000 |
| 0x48098184    | 0x00000000 |
| 0x48098188    | 0x00000000 |
| 0x4809818C    | 0x00000000 |
| 0x48098190    | 0x00000000 |
| 0x48098194    | 0x00000000 |
| 0x48098198    | 0x00000000 |
| 0x4809819C    | 0x00000000 |
| 0x480981A0    | 0x00000000 |
|----------------------------|

From register shows above, I can't see any different. And also, "Edma3ComplHandlerIsr" this callback not be called. So I this this example didn't run properly.

The most likely candidates are  the MCSPI registers, the EDMA registers, or the DMA crossbar registers.

Yes, I agree. And now we excluded MCSPI registers problem, can we just focus on EDMA regsters and DMA crossbar registers?

I know, if I got EVM board and run with JTAG of that example will be more clearly. But now I only have my product board with mcspi1 as slave. So I think the fast way to figure out this problem is dumped EDMA and DMA crossbar registers one by one to check if it has problem.

So back to what I say, would you please help me to check these EDMA and DMA crossbar registers below has problem? Or any other registers you think I should dump also?

root@dra7xx-evm:~# devmem2 0x43301024 (enable)
/dev/mem opened.
Memory mapped at address 0xb6f4e000.
Read at address  0x43301024 (0xb6f4e024): 0x0000000C

root@dra7xx-evm:~# devmem2 0x43305000 (0x43304000 + (128 * 32))) (PRAMset)
/dev/mem opened.
Memory mapped at address 0xb6f9f000.
Read at address  0x43305000 (0xb6f9f000): 0x80123004

root@dra7xx-evm:~# devmem2 0x4330226C (interrupt pending)
/dev/mem opened.
Memory mapped at address 0xb6ff4000.
Read at address  0x4330226C (0xb6ff426c): 0x00000000

root@dra7xx-evm:~# devmem2 0x4A002CBC (crossbar)
/dev/mem opened.
Memory mapped at address 0xb6f5b000.
Read at address  0x4A002CBC (0xb6f5bcbc): 0x00240023

Thanks for your patient!

Hi Zack,

After I change my EDMA_TPCC_SRC_n register, it called rx finished callback.But when I print rx dst buffer in this callback, I got 0. And also, this callback only  be called once. 

Do you know what's the problem it may be?

Thanks!

Hi Zack,

Today I found data zero problem is because I use "Utils_memAlloc(UTILS_HEAPID_DDR_CACHED_LOCAL, 128, 32);" to allocate memory. When I force this address to SR1_FRAME_BUFFER_ADDR which is used as share memory to A15, it works fine.

And for complete interrupt not coming after it has be called some times problem. It seems if I didn't handle one callback ASAP, it will never come in. Do you think I'm right?

Thanks anyway.

Hi,

Now I can receive data constantly, but there still have two questions:

1. Why I can't use IPU1 local memory as EDAM destination buffer? When I change SR1 memory, it receive fine.

2. When I disable interrupt more then 1 second, it will never receive EDMA complete interrupt anymore.

Hope someone can answer my questions.

Thanks!

HI,

1) When the memory is allocated from the "UTILS_HEAPID_DDR_CACHED_LOCAL", it's accessible only for that local core & not accessible to other core & DMA. So please use the below API to allocate memory from the shared region

Utils_memAlloc(
UTILS_HEAPID_DDR_CACHED_SR, size, alignment);

2) We are not recommending to disable the interrupt 1s, Why this much delay?

Thanks

Gaviraju

Gaviraju,

1) Thanks! I use UTILS_HEAPID_DDR_CACHED_SR

2) Yes, disable the interrupt 1s is not correct operation, but I think even I  disable the interrupt 1s, it shouldn't cause EDMA can't receive complete interrupt anymore.

Now I register lisrEdma3CCErrHandler0 as edma error handler, and Receive complete interrupt will get EDMA3_RM_E_CC_DMA_EVT_MISS will disable interrupt too long. But I'm not sure what should I do when I got this?

Thanks!

Hi,

Can you check with the lower interrupt disable latency? this is just to make sure the issue is reproduced with lower latency.

(Please try with 5ms, 10ms)

Thanks

Gaviraju

Hi,

One more question,  is there a possibility of posting multiple requests within this 1s delay? In this case. interrupt might get missed and so software will just keep waiting for the second interrupt completion.

Regards,

Brijesh   

Hi Tim,

I meant when you disable interrupt for 1sec, is there possibility that multiple DMA requests posted before that,?

Rgds,

Brijesh

Hi Brijesh,

Yes, my DMA requests should post every 500us.

BR/Tim

Hi Brijesh,

When I integrate my EDMA SPI driver with visionSDK usecase which is run on dsp, eve and ipu2 core. The EDMA complete and error handler interrupt go mess up. I think it should be conflit of EDMA resource, althougth I use EDMA LLD API which should guaruntee there it no conflict. But when I disabled some EDMA channel on IPU2, it run much better. 

And when I stop usecase, it run totally fine.

So, do you know which configuration did I probably missed?

Thanks!

Hi Tim,

ok, but do you post two DMA request, while the interrupts are disabled for 1s? or do you have multiple requests waiting, when you add sleep for 1s?

Regards,

Brijesh

Hi,

Yes, I have multiple requests waiting within these 1s.

Anyway, would you please help me to check my second question also :

When I integrate my EDMA SPI driver with visionSDK usecase which is run on dsp, eve and ipu2 core. The EDMA complete and error handler interrupt go mess up. I think it should be conflit of EDMA resource, althougth I use EDMA LLD API which should guaruntee there it no conflict. But when I disabled some EDMA channel on IPU2, it run much better.

And when I stop usecase, it run totally fine.

So, do you know which configuration did I probably missed?

Hi Tim,

I think EDMA channels are fixed for the McSPI driver and it is defined in pdk/packages/ti/csl/soc/Tda/cslr_soc_defines.h header file. Can you please sure that these channels are reserved in the core from where you are accessing McSPI? 

I think in vision sdk, EDMA channels are reserved in the folder \vision_sdk\links_fw\src\rtos\utils_common\src\dma_cfg. There is header files for EDMA channels allocation for each core. 

Rgds,

Brijesh 

Hi Brijesh,

Thanks for your reply!

I edit p/links_fw/src/rtos/utils_common/src/dma_cfg/utils_dma_cfg_sys_edma_tda2xx.c before: 

And from log IPU2 use channel 40 and 41:

And IPU1 MCSPI use channel 35 and 34. So I think it should no conflict. 

The weird thing is even I disable 40 and 41 channel in IPU2 MCSPI just goes better, but still have some wrong complete and error interrupt.

Thanks!

Hi Brijesh,

Since you closed ticket:  

so I continue this thread.

After I disbaled EDMA error interrupt handler and change MCSPI EDMA RX queue number from 1 to 0, it went much better even enable other EDMA channel.

But now the problem is Tx complete event is sometimes went after Rx complete event which should not happen, because Tx event number(34) is smaller than Rx event number(35) so it's priority should higher than Rx event. 

And from print log, I saw Tx event sometimes mess up, since it not be triggered when master finish sending, but be triggered when next sending began. And it will be triggered two times within this sending.

It is quite weird, would you please give me some clue?

Thanks a lot!