This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Cache coherency issue during EDMA in a Sys/BIOS application

Hi

We are observing Cache coherency issues in a Sys/Bios application.

Note on the Setup:

Hardware: TMS320TCI6482, Sys/BIOS 6.32.5.54

Problem:

In the code, we first transfer the contents from one buffer to another buffer which is located in the DDR. This is done using a memcpy operation. Before the copy we are performing the CACHE_FREEZE using the Sys/BIOS Api. After the copy we set the mode back to normal. This is done several times till the buffer in the DDR is not populated with the full contents. Following this we setup a EDMA to transfer the contents from the DSP to the FPGA. What we observe is the following:

1) The EDMA transfer does not get completed, it gets stuck somewehere between and the completion interrupt is not triggered.

2) On halting the core and browsing the memory, it is seen the contents in Cache are different from the ones in the DDR.

This application worked fine with DSP/BIOS.

Questions:

1) Are there some known issues while performing EDMA in a SYS/BIOS application?

2) The above appears to be a cache coherency issue because it was ensured that the Cache was Frozen at the time of memcpy. Still after EDMA has initiated, there is updation of contents in the cache.

Please suggest.

Regards

Dushyant

  • Dushyant,

    It seems the thing to focus on is the EDMA transfer getting “stuck” and not completing.  It seems that what you observe as incoherency could be due to the transfer not working as expected. 

    Are you writing to the EDMA registers directly or are you using helper or driver routines?  Can you verify that all the EDMA transfer parameters for the expected transfer are correct?  Can you tell by looking at EDMA registers why the transfer is not completing?  Have you been able to do other EDMA transfers to the FPGA and received completion interrupts as expected?

    Scott

  • Hi Scott

    Thanks for the quick response. We have validated the EDMA parameters and it seems to be setup Ok.

    The code is actually a migration from DSP/BIOS to Sys/Bios. However anything with respect to the EDMA is untouched as it was coded as per the CSL functions for 6482. The only difference in the code base is with respect to change to the BIOS APIs.

    I am going through the BIOS forum and a similar article is available:

    http://e2e.ti.com/support/embedded/bios/f/355/t/177742.aspx

    which suggests there are cache coherency issues while using EDMA in a Sys/BIOS application.

    Please suggest

    -Dushyant

  • Dushyant,

    Rewording what I’d said… I think any possible coherency issue is secondary at this point.  The first problem to solve is to get the EDMA transfers working.  Are you able to get any EDMA transfers with your FPGA working?

    For the thread you point to, it seems that the main issue was that cache was enabled when they moved to SYS/BIOS, but it wasn’t in their previous DSP/BIOS app.  With addition of the proper buffer invalidates and writebacks the app worked.

    When using CPU caches and DMAs together it is expected that the programmer be careful and do the necessary cache coherency operations.  This isn’t an “issue” with SYS/BIOS and EDMAs, it is a general programming practice, to maintain cache coherency when mixing CPU and DMA accesses to shared memory.

    Scott

  • Hi Scott

    Here is a note on the setup:

    The EDMA3 completion interrupt is mapped to Interrupt Event 24. The Interrupt event register is set by enabling the IESR for channel 48. GPIO0 for debugging purposes is setup to indicate the number of frames that get transferred. There is no Chaining of events and neither the EDMA is setup for intermediate transfer completion interrupts. The transfer is AB-synchronized.

    Issue:

    We have setup a global counter inside the ISR which services interrupt on GPIO0. It indicates only 2 frames got tranferred.We are expecting to transfer 80 frames. Beyond this, nothing happens and further processing gets affected.  

     I am wondering what could cause the transfers to crank-up?

    Please find attached the configuration of the EDMA3CC attached for reference

    Snapshot of the EDMA3TC Channel registers:

    Please suggest.

    Dushyant

  • Just to add, today I disabled the L2 cache and found that the transfer worked fine.

    Please comment.

    Dushyant

  • Dushyant,

    OK, thanks for the update.  I will ask someone more familiar with EDMA to look at this…

    Scott

  • Hi Scott

    Did anybody get a chance to look into the issue?

    Dushyant

  • Dushyant,

    I haven’t heard back yet from the person I asked to help with this.  I’ll let them know you’ve asked again…

    Scott