TMS320C6746: EMIFA Extended Wait Async mode and EDMA3 SPI

What devices are the EMIFA and SPI accessing?  What is the memory source and destination for both transactions?  From what you describe, i don't see where the two conflict.  Are the accessing the same memory space?

James

Hi James,

EMIFA interface was tested without external memory - memory stall was set with AWCCR.MAX_EXT_WAIT. EDMA3 SPI and EDMA3 UART were tested with various devices, including a personal computer using a factory-built converter. Losses were the same in all cases of simultaneous operation.

All interfaces use L2 RAM space: CPU reads data via EMIFA to the registers and writes data to L2 RAM buffer
in the next instruction, EDMA3 SPI reads and writes data to other L2 RAM buffers.
Is such use of L2 RAM space critical?
We tried to use L1D RAM as destination buffer for EMIFA, but the behaviour was the same - errors.

Best regards,
Irina

Irina, i don't think the memory that you are using is the issue.  In the first post, you said that EDMA is reporting missed events.  What is triggering each EDMA event?  Does it have anything to do with the EMIFA transactions?

Regards,

james

Hi James,

EDMA3 SPI events - SPIREVT and SPIXEVT - arise when a character is received and when a character is to be transmitted via SPI. These events are not related with the EMIFA transactions.

Best regards,
Irina

Irina, it seems like the same SCR (switched cental resource) is controlling both transactions, and when it has to wait for a long time because of the EM_WAIT, it is preventing other masters from accessing that memory

You may have to adjust the master priority in the system.  See section 10.3 of the TRM for more details.  Ensure the EDMA module you are using has higher priority than the CPU.  

Regards,

James

Hi James,

DSP MDMA default priority is 2. EDMA3_0_TC1 which is used for SPI default priority is 0 (highest). So EDMA module priority is higher than the CPU.

We set 7 (lowest) DSP MDMA priority via MSTPRI0. The behaviour was the same - errors.

Best regards,
Irina

Irina, since you are accessing the L2 RAM space, i believe you have to configure the Bandwidth Manager (BWM) inside the DSP subsystem, since that has control over those memories.  See section 2.2.2.3 of the TRM.  SPRUFK5 is the doc for the DSP Megamodule Reference Guide, which will have the details of this DSP peripheral.  

I think what you are trying to do is possible, we just have to figure out how to configure the internal paths to enable and prioritize it correctly

Regards,

james

Hi James,

CPU default priority for L2 access is 1 (CPUARBU register). SDMA priority for L2 access is dictated by the external system master transfer parameters, EDMA3_0_TC1 default priority is 0 (highest). So EDMA module priority for L2 access is higher than the CPU.
We set CPU L2 priority 6 via CPUARBU. The behaviour was the same - errors.

Errata (sprz304h) says "Advisory 2.3.1 - DMA Access to L2 RAM Can Stall When DMA and C674x CPU Command Priorities Are Equal", but default priorities aren't equal.

Best regards,
Irina

Irina, i think the distinction here is that the priority arbitration only comes into play for pending requests.  In your case, the EMIF request has already been granted and is in progress, and BWM is waiting for the for it to finish while the EDMA request arrives.  Thus it would have to abort the EMIF transaction (or somehow pause it) to let the EDMA transaction complete to the L2 RAM.  I don't think this is happening.  

Just as an experiment, do you have another memory in your system to work with, just to see if the bottleneck is the L2 RAM?  I'm not suggesting this as a solution yet, just want to confirm the final operation is functional.   

There is a small memory in the PRUSS that you might be able to use for this purpose.  

Another idea is to reduce the MAXWAIT parameter as mentioned in the errata note.  This may allow the EDMA transaction to complete.

Regards,

james