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.

Simultaneous DMA and CPU access to different SARAM blocks

Hi,

In our VC5505 board, we are using DMA to transfer data to I2S from one SARAM block and while accessing the other block of SARAM from CPU.  We noticed if CPU tries to access SARAM in each cycle the samples sent out by I2S will be corrupted once in a while, even though DMA and CPU are accessing different blocks of SARAM. If we add a nop in between the CPU's continuous access of SARAM , the problem goes away.   It's our understanding that different blocks of 8K SARAM can be accessed simultaneously, so that no memory access conflict should occur in our case.  We are wondering if there is any limitation / consideration related to this issue.

 

Thanks

A shen

 

  • Hi A shen,

    Your understanding is correct.

    Where is your code located in memory? Which block? (you can look at the map file)

    Can you send us the project?

    Regards,
    Mark

  • Hi Mark,

    The following is the word address of the SARAM we are using

                00008000    _i2sDmaTxIBufA

                00008400    _i2sDmaTxQBufA

                00010000    _i2sDmaTxIBufB

                00010400    _i2sDmaTxQBufB

    Basically, we are using A/B ping pong buffer, with DMA using BufA and DSP using BufB then switching. Program code starts at  word address 0018000h. 
    The code at CPU causing trouble looks like
    for (i = 0; i < len; i++)
    {
    data[i] = (data[i] << sval) + (aval << 8); 
    // asm(" nop");
    }
    After assembly the code inside the loop is
                AC0 = AC1 + (*AR0 << T2) ; |106| 
                *AR0+ = AC0 ; |106| 
    So the CPU will be keep accessing SARAM every clock for the loop duration. And this will cause some corrupted data seen on I2S.  If we add one extra nop in the above loop,
    the problem is gone.
    The project has quite a few files and several of them are our hardware dependent. The problem reveals itself through the corrupted samples from I2S to DAC (we observed the DAC output waveform on oscciloscope). So not sure if sending the project will be helpful. 
    Thanks
    A shen