OMAP L138 EDMA3 transaction does not get finished

Hi Sivaraj 

Thanks for your response.

I'm trying different scenarios now, but so far no luck yet.

I'm wondering what is the most probable cause for EDMA channel to stall short of transaction completion?

Thanks again

 Andrey

Hi,

My guess would be, TC servicing the SPI peripherals should be at higher priority at the event queue and kindly make sure the EDMA3 TC's priorities configured in the master priority 1 register (MSTPRI1) and again EDMA3TC can be controlled by the queue priority register (QUEPRI) in the EDMACC memory map.

Thanks & regards,

Sivaraj K

-------------------------------------------------------------------------------------------------------

Please click the Verify Answer button on this post if it answers your question

-------------------------------------------------------------------------------------------------------

Hi Sivaraj

Thanks again for the response.
I tried to change priorities on EDMA TC controllers:
Defaults are both 0 - highest.
So I configured SPI-related EDMA channels to have priority 0 and (TC1) and the rest channels to have priority 4 (TC0).
Still issue stays there.
If I try to reduce/ rearrange SPI clocks - seems like system gets more stable. But that is not what we want.
Do you have any other suggestions.

Thank you.

Andrey

Hi
What is your definition of "stall" ,
1) Do you see the SPI transfers not completing in expected time frame due to contention but eventually completing
2) or Do you see SPI transfer not completing ever and just stuck ( as i infer from you saying that transfer completion interrupt is not generated)

#2 cannot happen because of contention... even if there is contention on the busses , eventually the transfer will get through and complete, there should be no data loss or infinite stall - unless there is something more fatal in your system or software

For contention related stuff
1) Ensure SPI -EDMA transfers are the highest priority in the system. (compared to any other initiator in the system, not just the other TC)
2) Try to experiment with reduced SPI clock , i see you have done that... can you elaborate what freq works /stable vs what fails
3) Assuming 2 is not acceptable, try to isolate SPI traffic
a) By using the Queue-TC servicing SPI DMA , exclusively for SPI transfers ..all other transfers should be on the second TC or if there are memory to memory transfers they could be on the other CC-TC
b) By using "different" memory buffer for SPI buffers, e.g. if everything was in DDR, you can try to see if you get better stability by putting the SPI traffic on unused or less used memory like Shared RAM or DSP L2 (if these SPI transfers are being consumed by DSP side etc)
4) If for whatever reason everything is in DDR, ensure that DDR BPRIO register is set to something lower than default , the default is 0xff, usually uboot or some place this is set to 0x20 etc.

Hope this helps some...
If not , please further elaborate all the masters, initiators and their source/destination in your current stress /tests system.
Regards
Mukul

Hi Mukul

Thanks for the response and suggestions.
Bu stall I mean incompletion of EDMA transaction - there is usually 1 or two bytes left (say for one-dimentional transaction and word size of 1 byte BCNT retains value 1 or 2 (bytes remain) and ACNT has value 1(word size) ). And it never cleans up automatically - I do it manually.
I suspect that SPI event may had been lost, but at the same time I do not enable intermediate interrupts.
I'm working only in internal memory space and for SPI data buffers I use DSP RAM (256K) (we do want to save on power, so DDR is not an option).
DSP memory also used for OS stack pool and some other buffers.
Also I'm using TC1 exclusively for SPI traffic.
I'll try to rearrange system priorities to see if it helps.
Thanks again

Andrey

>>Bu stall I mean incompletion of EDMA transaction - there is usually 1 or two bytes left (say for one-dimentional transaction and word size of 1 byte BCNT retains value 1 or 2 (bytes remain) and ACNT has value 1(word size) ).

Andrey

This does not sound like a traffic contention issue , either something wrong in the software driver for SPI-EDMA or system software causing something an issue (if this SPI_EDMA works stand alone but fails/looses bytes in conjunction with other traffic). 

It would be good to check the status of EMR and SER bits when you see this happen. It would be good to have EDMA error interrupts enabled in your system to catch any erroneous behavior. 

Regards

Mukul 

Hi Mukul

Thanks again for suggestions.
I did not see messed events in EMR register.
Interestingly enough - I bumped up CPU frequency and now it seems to work reliably.
I still will will play with it to understand exactly the cause of the failures.

Andrey