Srio DMA to DDR?

DSP C6457

DioiLib Version 1.1.0

All examples use L2SRAM. Whe I initially built my application it was running in DDR space, and was able to receive data from  the edmaSteaming test code at the address 0x900000. But whe I tried to send data from memory malloced in DDR (0xE0000000) and above, the data did not appear in the memory. It appeared as if caching was going on on the receiving L2  memory. Inspection of the megamodule registers indicated that chaching was disabled in L2. Once we force everything to run from L2, out data began appearing as expected.

It appears as if extra steps are required to DMA from DDR

Robert,

If you view the memory in DDR with the CCS Memory Browser, it will show you the contents in the caches and in the physical memory. If the problem is caching, an easy way is to clear all of the MAR bits to 0, or at least the ones for the DDR space. You can add the following to your GEL file to be called from another GEL function or make it into a menuitem:

MAR_setup(unsigned MarValue)
{
  int i;
  unsigned int *ptr=(unsigned int*)0x01848380;
  //DDR EMIFB setting it for no caching [16Mbytes per MAR bit]
  //0xe0000000-0xefffffff
  for ( i = 0; i < 16; i++ )
    *ptr++ = MarValue;
}

Call it from OnTargetConnect as MAR_setup(0); to turn off all the MAR bits, which is their power-on default. If your code sets the bits, you can change that code, of course.

This will determine if the problem is caching or not when you are using DDR. If so, then the solution may be to execute the appropriate cache coherency commands to keep cache and DDR up-to-date.

Regards,
RandyP

Randy,

I do not believe the problem is cache. When the application executed from DDR with the Srio destination address in L2 and source address in DDR, no data was received at the L2 address, even though the LSU indicated the transfer had completed. Inspection of the cache control registers of the megamodule verified that L2 cache was disabled. Inspection of our working edmaStreamingTest from the DioLib using the debugger revealed that it was executing from L2 and was performing mallocs in L2, so it was performing Srio transfers to/from L2 memory only. Once we changed our application to execute only from L2, with no other changes, the application began performing correctly, leading us to believe something extra must be done to use a Srio source address in DDR and the target address in L2 

Bob Coburn

Randy,

I do not believe this is a cache issue, it on;y looks like one. Viewing the cache control registers in the MegaModule show that L2 cache is disabled. Our desired configuration is to use DDR memory as the Srio source and L2 as the destination. We have 2 6457 LE eval boards from eInfoChips with lane 0 of the srio connected. Our final application was originally built using DDR with L2 as the srio destination, but our edmaStreamingTest from DIOlib was built to use L2 for program, stack and heap, again with L2 as the srio destination. When we discovered this discrepance, we reconfigured out application to use L2, at which time Srio DMAs began operating correctly, leading us to believe another step is required to use DDR as the source address

Randy,

I do not believe this is a caching issue, it only behaves like one. I have 2 C6457LE eval boards from eInfoChips, with lane 0 of the Srio connected. We have the edmaStreaming test from DioLib successfully executing. This was built to use L2 for program, stack and heap with L2 as the srio destination address. Our application was built to use DDR, but the Srio destination is still L2. This is to be our final configuration. The edma streaming test exectues correctly, but our application never received DMA data leading us to suspect cacheing. When we realized the difference between L2 and DDR we reconfigured our application to use L2 as we had in edmaStreaming at which time the application began functioning properly leading us to suspect that something else is required to used DDR as the source address. I believe that we have also successfully sent data drom edmaStreaming to our application. Again a L2 to L2 transfer. What seems to have problems is a DDR to L2 transfer.

Bob Coburn

Bob,

There is no reason I can see from the device architecture that would cause this to be a problem. A subtle speed-related issue is conceivable, but this would seem unlikely to me.

We need to narrow down the issue to a single item that changes, or start debugging from the bottom up.

I recommend starting with the edmaStreaming example in L2. Confirm that you can access the DDR space through the CCS emulator and initialize 0xE0000000 on the target so you will be sure whether it was updated or not. Then just change the destination address to 0xE0000000 without any other changes.

Please let us know what you find from this test.

Regards,
RandyP