Problem with C674x DMA

Leon Wang,

Could this be a cache or display issue? If the DDR2 bufb has been read by the DSP and the data is stored in cache, then you copy from bufa to bufb, the cached copy of bufb will still reside in the DSP's L1D or L2 cache area. In a CCS Memory Window, you can tell if the data is in cache or not by the highlighting color. Also, you can uncheck the cache control boxes to see what is in the actual DDR2 memory location.

Which processor are you using?

Which board, an EVM or your own board?

Which version of CCS are you using?

Regards,
RandyP

If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

RandyP,

I have try to disable the L1D Cache and L2 Cache, but the problem is still.

I not use CCS, all develop is with Codec Engine in Netra sdk 5009.(the FC version is 3.21,)

I use the C674x DSP core in TI816x.

Leon Wang,

You may want to look at the tools called C6Flo and C6Run. But you should also be able to do what you want to do the way that you are doing it.

Debugging code that is being developed on the DSP is usually done with CCS, so you will have a lot less control and visibility from the Linux side. I understand that a lot of Linux programmers prefer it that way, though.

You have tags on both of your posts that name other TI devices, different from the one you are using. And the name TI816x is not the name of a TI device but is an internal term used still on some of our emulation Target Configurations and some software products.

Which device are you using? And what board are you using, your own or a TI EVM (which one)?

Usually, all of L1D is configured as cache and not SRAM. You should never access cache memory directly, so you will need to make sure how the cache is configured for both L1D and L2.

Since your transfer works for DDR3 to DDR3, there must simply be an address error when you try to access the internal memory. Try poking and peeking some of those locations from Linux to see if you can reach them, although you will have to figure out the MMU setting, I guess, to get there. The MMU setting is not required for the EDMA, by my understanding.

Regards,
RandyP

Hi Leon and Randy

Well I am facing the same issue. I am using QDMA and the DDR to DDR transfer is working good. But when i allocate the source buffer in L2, I mean L2 to DDR transfer i can see all zero values. I have filled the destination memory to some values before transfer and it becomes zero after transfer. this means that transfer is working. 

I think its not a cache issue because if it is then at-least wrong L2 values i.e non-zero ones should appear in  destination. My external memory is non-cacheable and i have 32 Kb L2 cache configured.

Leon, any idea how did you fixed this issue. Any thing related to address translation? One more info ...i am using DM8148 DSP and working with CCS on Windows

Hope i get some response soon.

Regards

Abhishek 

Abhishek,

My guess is that you are using the wrong source address for L2. There are several tables in the DM8148 datasheet that help you understand how the different modules access the different memory components.

Are you programming and running the QDMA from the C674x?

Regards,
RandyP

Hi Randy

I am using RTSC config for DM8148 which is default in the packages and has the proper memory range. I checked the data sheet too. And for my source buffer i am using DATA_SECTION pragma to allocate in L2 SRAM using bios config. So source seems to be correct to me.

Yeah i am programming and running the QDMA from the C674x. I am using DM8148 EVM

Regards

Abhishek

Abhishek,

What 32-bit hex address are you using for the QDMA SRC address for the C674x L2 memory?

If you are setting OPT.STATIC=1, then you can set a breakpoint in your code just after starting the transfer. Examine the 8 QDMA PARAM registers for your channel and post those here. Or set the breakpoint prior to starting the transfer and use the debugger Variables or Expressions window to observe the value of the variable that will be written to the SRC register.

If your L2 SRC address starts with 0x008xxxxx then it is wrong for the EDMA3 module to access. I am not sure if the right address starts with 0x108xxxxx or 0x408xxxxx, but you could try adding the offset to your SRC address and see if it works for you. But without the 32-bit hex address, I am guessing.

Regards,
RandyP

hi  I also have the same problem,but wo I do not know how to do ,I use 8148 platform ,and develop in the linux os,can you tell me modfiy the files.

var mem_ext = [
["DDR3_HOST", {
    comment:    "DDR3 Memory reserved for use by the A8",
    name:       "DDR3_HOST",
    base:       0x80000000,
    len:        0x0B000000,
    }
],
["DDR3", {
    comment:    "DDR3 Memory reserved for use by the C674",
    name:       "DDR3",
    base:       0x8b000000,
    len:        0x01800000,
    }
],
["DDRALGHEAP", {
    comment:    "DDRALGHEAP: off-chip memory for dynamic allocation",
    name:       "DDRALGHEAP",
    base:       0x8C800000,
    len:        0x00800000,
    }
],
["DDR3_SR1", {
    comment:    "DDR3 Memory reserved for use by SharedRegion 1",
    name:       "DDR3_SR1",
    base:       0x8D000000,
    len:        0x00C00000,
    }
],
["DDR3_SR0", {
    comment: "DDR3 Memory reserved for use by SharedRegion 0",
    name: "DDR3_SR0",
    base: 0x8E000000,
    len:  0x01000000    /* 16 MB */
    }
],
];

/* platform instances used by this package */
Build.platformTable["ti.platforms.evmDM8148"] = {
    externalMemoryMap: mem_ext,
    l1DMode:"32k",
    l1PMode:"32k",
    l2Mode:"128k",           
    codeMemory: "DDR3",
    dataMemory: "DDR3",
    stackMemory: "DDR3"
};

var DMAN3 = xdc.useModule('ti.sdo.fc.dman3.DMAN3');
DMAN3.heapInternal    = "INT_HEAP";       /* INT_HEAP is an internal segment */
DMAN3.heapExternal    = "EXTALG_HEAP";
DMAN3.idma3Internal   = false;
DMAN3.scratchAllocFxn = "DSKT2_allocScratch";
DMAN3.scratchFreeFxn  = "DSKT2_freeScratch";
/*  Next, we configure all the physical resources that DMAN3 is granted
 *  exclusively. These settings are optimized for the DSP on DM6446 (DaVinci).
 *
 *  We assume PaRams 0..79 are taken by the Arm drivers, so we reserve
 *  all the rest, up to 127 (there are 128 PaRam sets on DM6446).
 *  DMAN3 takes TCC's 32 through 63 (hence the High TCC mask is 0xFFFFFFFF
 *  and the Low TCC mask is 0). Of the 48 PaRams we reserved, we assign
 *  all of them to scratch group 0; similarly, of the 32 TCCs we reserved,
 *  we assign all of them to scratch group 0.
 *
 *  If we had more scratch groups with algorithms that require EDMA, we would
 *  split those 48 PaRams and 32 TCCs appropriately. For example, if we had
 *  a video encoder alg. in group 0 and video decoder alg. in group 1, and they
 *  both needed a number of EDMA channels, we could assing 24 PaRams and 16
 *  TCCs to Groups [0] and [1] each. (Assuming both algorithms needed no more
 *  than 24 channels to run properly.)
 */
DMAN3.qdmaPaRamBase = 0x09004000;
DMAN3.paRamBaseIndex     = 80;  // 1st EDMA3 PaRAM set available for DMAN3
DMAN3.numQdmaChannels    = 8;   // number of device's QDMA channels to use
DMAN3.qdmaChannels       = [0,1,2,3,4,5,6,7]; // choice of QDMA channels to use
DMAN3.numPaRamEntries    = 48;  // number of PaRAM sets exclusively used by DMAN
DMAN3.numPaRamGroup[GROUP_2] = 0; // number of PaRAM sets for scratch group 2
DMAN3.numTccGroup[GROUP_2] = 0; // number of TCCs assigned to scratch group 2
DMAN3.tccAllocationMaskL = 0;          // assign no TCCs 0..31 for DMAN3
DMAN3.tccAllocationMaskH = 0xffffffff; // assign all TCCs 32..63 for DMAN3

All,

The issue for address translation required while using EDMA to access DSP internal buffers is summarized here:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/145751.aspx

For people programming the EDMA using framework components, might find this post useful.

http://e2e.ti.com/support/embedded/bios/f/355/p/122497/436725.aspx#436725

Regards,

Rahul