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.

Video processing on DM643x: glitches when transferring data between IRAM and DDR in a double-buffering scheme.

Hello everyone,

 

I'm using a double-buffering scheme for my video signal processing application and I'm having some cache coherency problems (I guess) when using DMA between DDR and IRAM. 

 

Here is what I do, schematically: 

 

1. Call FVID_Exchange for the VPSS's CCDC (get a new frame)

2. Send a chunk of this frame from the DDR to the L2 SRAM and process it using DMA.

3. Call FVID_Exchange for the VPSS's Video0 window (send the frame back to the VPBE)

 

I'm getting some annoying glitches on the frame when I transfer data from the DDR to the SRAM using DMA. It looks like my L1D/L2 cache are getting corrupted. 

 

Some remarks:

- My video frames are in a cacheable region (using MAR bits)

- When I memcpy the same data from the DDR to the SRAM, no problem at all.

- If I transfer data from the SRAM to the DDR, no problem at all.

- If I enable the cache (using BCACHE_setMode()) during video processing only, it helps but having no cache enabled for other tasks is not acceptable. 

 

Can anyone help me out with this ? 

 

Best Regards,

 

Romain Farkas

  • This certainly sounds like a cache coherency issue, if you are not running any BCACHE commands to deal with coherency you will likely end up with cache artifacts. Essentially the video ports and the DMA operate outside of the caching structure of the CPU core, so if you have cached data that has been updated by a video port or DMA transfer than the CPU will still see the old data, conversely if the CPU updates some data in its cache that does not get the opportunity to write back to external memory than the video ports and DMA will not see the updated data. This being said when the DMA or video port is bringing in data that will be operated on by the CPU you must invalidate the cache for that region such that the CPU will see all the new data, and when the CPU is done working on data that will be given to a video port or DMA than you will need to write back the cache for that region, so the data the CPU updated gets reflected in external memory.

    There is an article on cache coherence on the wiki here, and the accessing pixels in a frame document here uses a cache operation to maintain coherency.

    I assume the glitches take the form of flickering horizontal lines? This is typically what I have seen when cache coherency was not properly maintained in a video system.

  • Bernie,

    I did some additional debugging and realized it wasn't maybe a cache-related issue. I'm thinking about a DMA priority conflict between the VPSS and my application. 

    Our platform is the DM6437. I'm using the CCDC port with a 752x480 imager connected as a RAW input. Then we have a Preview engine de-bayering + YCbCr 4:2:2 conversion. Finally we have a 752x480 YCbCr 4:2:2 video window on the VPBE.

    Basically, here is what we do:

    - Exchange buffers between CCDC and VPBE (this includes acquisition, debayering and display) using FVID_exchange API calls
    - 100x DMA write between external memory and internal memory (L1D mapped memory) 

    What's interesting here is that the VPSS's PCR.PRV_WBL_O flag is on when we do these DMAs (so are the flickering horizontal lines). The PRV_WBL_O flag vanishes as soon we disable our DMAs.

    Therefore I'm checking now the VPSS priority !

    Does it make sense to you ?

    Regards

    Romain Farkas

  • It could be a memory bandwidth issue, seeing PRV_WBL_O set would indicate such and broken real time deadlines in the video subsystem can appear as artifacts that look similar to cache coherency issues. The VPSS has the highest priority already by default, however so do the EDMA channels, so it may be worth trying to lower the priority of the channels that are not as time critical with the appropriate EDMA QUEPRI register fields. The system priority scheme is discussed in section 3.6.1 of the datasheet.

    There is also a register in the DDR controller that may have some impact here, in particular the PBBPR register has the ability to adjust how long DDR transfers stay in the FIFO before yielding to older transfers, this register is discussed in section 4.6 of SPRU986b.

  • Got it ! 

    You were right. I lowered the priorities of my EDMA channels to 7 (as suggested in a previous post related to a similar problem with the EMAC). I also lowered my VPSS frequency to 27.2 MHz (instead of 75 MHz) which helped to reduce the overall load on the bandwidth (FMTCFG.VPIF_FRQ). 

    Thank you for your help ! [:Y]

    Romain Farkas