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.

The data number of MSMC to DDR3

Hello,

The question is that :

I test the dma  transfer between MSMC and DDR3.

When the dma length is over 0x40000(256KB),the data is not transfered completely,the data at the end of dma(over 1k) is not transfered.

I want to know why?

Thanks in advance!

  • Jie,

    Most likely it's do to incorrect configuration of the EDMA.  Can you provide the PaRAM entry values used for the transfer that is failing?

    Best Regards,
    Chad

  • Chad,

    My PaRAM entry values used for the transfer that is failing is as follow:

    myParamSetup.option = CSL_EDMA3_OPT_MAKE(CSL_EDMA3_ITCCH_DIS, \
     
     CSL_EDMA3_TCCH_DIS, \
     
     CSL_EDMA3_ITCINT_DIS, \
     
     CSL_EDMA3_TCINT_EN, \
     
     0, CSL_EDMA3_TCC_NORMAL,\
     
     CSL_EDMA3_FIFOWIDTH_64BIT, \
     
     CSL_EDMA3_STATIC_DIS, \
     
     CSL_EDMA3_SYNC_AB, \
     
     CSL_EDMA3_ADDRMODE_INCR, \
     
     CSL_EDMA3_ADDRMODE_INCR );
     
     myParamSetup.srcAddr    = (Uint32)srcBuff1;
     
     myParamSetup.aCntbCnt   = CSL_EDMA3_CNT_MAKE(1024,len_KB);

    //when len_KB is over 256, the dma length is over 0x40000(256KB),the data is not transfered completely,the data at the end of dma(over 1k) is not transfered
     
     myParamSetup.dstAddr    = (Uint32)dstBuff1;
     
     myParamSetup.srcDstBidx = CSL_EDMA3_BIDX_MAKE(1024,1024);

    myParamSetup.linkBcontrld = CSL_EDMA3_LINKBCNTRLD_MAKE(CSL_EDMA3_LINK_NULL,0);
     
     myParamSetup.srcDstCidx = CSL_EDMA3_CIDX_MAKE(0,0);
     
     myParamSetup.cCnt = 1;

    Best Regards,
    Jie

  • Jie,

    Can you provide a screen capture of this PaRAMs entry values in the memory window (please stretch the window to display 8 columns of words) when the issue shows up?  Are you sure that you haven't overran the src data buffer?  If you go into invalid data space it should complete w/ the rest as null transfers.

    Can you confirm what device and board this is, I just want to make sure we're not talking about a simulator or something.

    Best Regards,

    Chad

  • Chad,

    I run on the TMX320C6678L,and I am emulator.

    And when the error happend,

    the PaRAMs entry values in the memory window is as follows:

      0x02704040: 80100304 80000000 01000400 0c100000 04000400 0000ffff 00000000 00000001

    the src memory is as follow:

    0x800001d8: deadbf65 deadbf66 deadbf67 deadbf68 deadbf69 deadbf6a deadbf6b deadbf6c

    0x800001f8: deadbf6d deadbf6e deadbf6f deadbf70 deadbf71 deadbf72 deadbf73 deadbf74

    0x80000208: deadbf75 deadbf76 deadbf77 deadbf78 deadbf79 deadbf7a deadbf7b deadbf7c

    the dst memory is as follow:

    0x0c1001d8: deadbf65 deadbf66 deadbf67 deadbf68 deadbf69 deadbf6a deadbf6b deadbf6c

    0x0c1001f8: deadbf6d deadbf6e 56789abc deadbf68 56789abc 56789abc 56789abc 56789abc

    0x0c100208: 56789abc 56789abc 56789abc 56789abc 56789abc 56789abc 56789abc 56789abc

      56789ab is initial value of dst memory

     Best Regards,

    Jie

  • Jie,

    I assume this is the 'passing' setup, because it's setup for 256KB xfer, which you claim is working up to 256KB.  What's the failing PaRAM setup values?  What's the value of Len_KB when you do this?

    Best Regards,

    Chad

  • Chad,

    This is a failing PaRAM setup,when it's setup for 256KB,it is already fail.

    And the source and dest memory is as follow:

    the src memory is as follow:

    0x800001d8: deadbf65 deadbf66 deadbf67 deadbf68 deadbf69 deadbf6a deadbf6b deadbf6c

    0x800001f8: deadbf6d deadbf6e deadbf6f deadbf70 deadbf71 deadbf72 deadbf73 deadbf74

    0x80000208: deadbf75 deadbf76 deadbf77 deadbf78 deadbf79 deadbf7a deadbf7b deadbf7c

    the dst memory is as follow:

    0x0c1001d8: deadbf65 deadbf66 deadbf67 deadbf68 deadbf69 deadbf6a deadbf6b deadbf6c

    0x0c1001f8: deadbf6d deadbf6e 56789abc deadbf68 56789abc 56789abc 56789abc 56789abc

    0x0c100208: 56789abc 56789abc 56789abc 56789abc 56789abc 56789abc 56789abc 56789abc

      56789ab is initial value of dst memory

    You can see the error is happening.

    Best Regards,

    Jie,

     

  • Jie,

    How are you observing this?  Are you using the emulator to read the locations are C code and checking?

    If the Core is checking this, and you've already read that address, it could have the old data in cache.  For a DMA into the Multicore Shared Memory Space 'MSMC' (0x0C10 0000 is in MSMC) it will not remain coherent w/ L1D, you'll need to do an invalidation of the cached locations for the CorePac to re-cache this data.  Please refer to the C66x Cache UG sprugy8.pdf.

    If you open it up in a memory window w/ CCS you should see the values actually in memory (you can get a cached view as well depending on which boxes you have checked.)

    Best Regards,
    Chad

  • Chad,

    I try to use DMA to transfers data from DDR to MSMC DataCnt=0x40000,that is 256kand find that the data in MSMC is not the same as the transferred data,  from 0xc100000 to 0xc18bc, the data in MSMC is ok,but from 0x0c181c0 to 0x 0c18200 (MSMC address:0x0c100000), the data is the old data in cache ,not the updata data,but I do invalidate the cache for those locations before dma transfer start .why this wouldn’t happen when I decrease the DataCnt to 0x20000

       I check the the C66x Cache UG sprugy8.pdf, and find one cache operation can operate on at most 4*65408 Bytes. that is 255.5K,is that mean if I want  to use dma to transfer the data to MSMC , the DMA length must be limited to 255.5K or less. If not ,how can I save this And what can I do if I want to transfer the data from DDR directly to MSMC, not through the cache?

         Before the DMA  My code is :

          CACHE_wbL1d((void *)pl2Data,DATA_CNT,CACHE_WAIT);

          CACHE_wbL2((void *)pl2Data,DATA_CNT,CACHE_WAIT);

          DATA_CNT is the data number of  DMA.pl2Data is the address of MSMC.

         

  • Jie,

    You should be invalidating the data after it's transferred not before it's transferred.  If for some reason it's read (and recached) between the time you invalidated it and the new landed data then you'll still have an old cache copy.

    The DMA length is not restricted by the cache coherence operation size, you may need to do multiple local invalidates (or a single global invalidate) on a cache to cover the desired range.

    Have you used the CCS emulation memory window to view if it's shown as cached or not?

    Best Regards,
    Chad