TMS320C6657: EDMA3 With UART Problem

If they stop EMIF16 EDMA3, UART can received 50K of continuous data without problem. UART running at 915000 baud, and its FIFO is enabled.

They are using bios_6_45_01_29.

Customer using McSDK 2.1.2.6. Company policy doesn’t allow releasing of code, they can provide regiester dumps if needed.  If there are specific address needed, let me know.

UART uses EDMA3 queue 0 and EMIF16 uses queue 3.

Here are the calls to open the EDMA3 channels.

UART:
    chParamBRx.regionNum = CSL_EDMA3_REGION_GLOBAL;
    chParamBRx.chaNum = 14
hEdmaUartBRevt = CSL_edma3ChannelOpen(&edmaUartBRcvObj, 2, &chParamBRx, &uartStatus);

EMIF16:
chAttr.regionNum = CSL_EDMA3_REGION_GLOBAL;
chAttr.chaNum    = 1;
EMIF16hChannel = CSL_edma3ChannelOpen(&EMIF16chObj, 2, &chAttr, &status);

Hi Lawrence

As discussed offline

The above info does not clarify whether UART and EMIF were indeed on separate queue/TC, similar to the init code above you can share the DMAQNUM setup or register dump to double check.

CC.QUEPRI register could be set differently for Q0/TC0 vs Q3/TC3 . Was this tried?

Additionally in previous post you had the following response

1) SRC/DST for UART and EMIF traffic on c665x but would like to make sure for test vs long term application TI understand where does UART and EMIF payload need to reside. It may not be a bad idea to keep the UART vs EMIF on different memories to further avoid resource contention.

>>: All EDMA3 parameters are sent you. UART and EMIF16 receive buffers are in L2 internal memory. I tried to each out and that causes problem.

What does highlighted section imply? Can they tr to have UART in L2 memory and EMIF16 payload in DDR memory just for test purposes

It is important to see if this is a  EDMA  or src/destination bottleneck or something wrong with the way the interrupts/auto reload/ initialization  of UART vs EMIF16 is being handled. 

When they say that the UART receive is ongoing, but no updates in UART registers, did they see what is the CC registers like ER, EMR , SER etc>

As previously requested if they cannot share code, maybe they need to share the CC reg dump 

Mukul,

They played with different combinations of the priority, no change in the issue.   The conclusion is the existing setting is the optimal.

Here is the DMAQNUM register dumps.

Here is the correct register dump

I also reconfirmed they tried different priority scheme but having them all the same worked the best overall.

UART Register dump:

Answer to your questions:

How are you writing the event handlers / ISR for EMIF16 vs UART transfer completion? 

>>EMIF16 DMA is single shot and UART Rx DMA is continuous.

They also indicated that there are no accidental clear of latched events

Just a reminder of the issue they are seeing:

2. When UART receives more than 30 bytes, It shuts down.  Meaning the UART will not receive any data.  I can see UART line has received data on scope.  But the its holding register shows previous value without change.

3. If I stop EMIF16 EDMA3, UART can received 50K of continuous data without problem.  Our UART running at 915000 baud, and its FIFO is enabled

Is there anything else you want me to ask them to try besides separating the EMIF16 and UART receive buffer to a different memory?

Mukul,

Response from the customer:

1. Put EMIF16 and UART receive buffers in different memory (not both in L2) 

>> I putEMIF16 buffer in MSMC and vis versa.  Doesn’t work.  Both memories have to be in L2.

2) See if it possible to break the EMIF16 transfers into smaller chunks per transfer request - I believe the EMIF16 transfers are important and real time as they had something to do with audio - however if it is not performance critical , they can also try to increase the time between every transfer by increasing the value for time between TC reads by programming the RDRATE register in TC.

>> Due to real time issue, we cannot break the transfers nor wait longer time in between.

Regards,

Lawrence

Raja,

Answers to your questions:

How the UART RX DMA is triggered? As per the your register  configuration, SRC is UART0 RBR, destination is L2. Once the channel using Param set 9 is triggered, it will trigger the channel using param set 10 continuously as it is linked to itself

>Customer continuously trigger DMA using link reload and circular buffer.

Can you try the EDMA channel triggered by RX event when the FIFO reached to certain level?

>Yes, FIFO is triggered at 1 byte level. 

ACNT = 1 and BCNT = 0x8000 with A-sync, SRC in incremental mode. DST in incremental mode. Given SRC is FIFO with 16-bytes depth, it is not clear the use of incremental mode.  

>For UART received register address, both INC or CONST works the same

Why BCNT = 0x8000?

>this is the size of circular buffer.