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.

Disabling caching

Other Parts Discussed in Thread: SYSBIOS

Hi,

How can I disable caching in C6678 so that I can DMA my data from DDR3 to whole of L2SRAM (all of 512K in case of C6678). I tried including the following in my cfg file:

var Cache = xdc.useModule('ti.sysbios.family.c66.Cache');

and then disabling it in my code by adding the following line:

Cache_setSize(ti_sysbios_family_c66_Cache_L2Size_0K);

But when try to load the program into one of the core I get the following error:

C66xx_0: Trouble Reading Memory Block at 0x6bbb78b0 on Page 0 of Length 0x1: (Error -1202 @ 0x6BBB78B0) Device core is hung. The debugger will attempt to force the device to a ready state to recover debug control. Your application's state will be corrupt. You should have limited access to memory and registers, but you may need to reset the device to debug further. (Emulation package 5.0.747.0)
C66xx_0: 9 other operation(s) were automatically canceled as a result

Thank you in advance

Barath Ramesh

  • Barath,

    Are you doing the DMA to L2 copy when this error occurs?  Or did you only add the useModule() to the application configuration and then build and try to load the program?

    If the DMA is not being invoked: is CCS configured to "go main" on a program load?  If so, can you disable that go main and then step into the startup sequence to see where the problem occurs?

    If you are indeed doing the DMA when this happens: What address range is the DMA writing to (local versus corepac address)?  Where in the application is the DMA being initiated?  Is the EMIF configured properly for the DMA to access DDR3?  How are you detecting DMA completion, and if via an interrupt, is that interrupt enabled?  Did you try doing the copy first as a CPU copy to see if that works, before trying it with DMA?

    Thanks,
    Scott

  • Scott,

    Thanks for the reply, the problem occurs when I add useModule() and try to load the program after building it. I am not sure if CCS is configured to "go main" on program load, I will give it a shot and try to figure out where  program  load gets stuck. I was able to successfully transfer 1K data from DDR3 to L2SRAM (destination address: 0x10800000, CorePac0 L2 start address). But the DMA data transfers where erroneous  when I tried transferring 256KB of data to L2SRAM which is when I realized that I have to manually disable caching since BIOS automatically enables it. Please correct me if I am wrong. 

    Thanks,

    Barath Ramesh

  • Barath,

    Yes, caching is usually enabled by default, but if the L2 cache size is set to zero I wouldn’t expect a problem when you tried to use that region.

    Did you find if CCS was doing auto go main?  

    Thanks,
    Scott

  • Scott,

    I checked my RTSC platform and L2 cache size is set to 0K. Also, I am able to load the program successfully to core0 after I rebooted my system and rebuilt the project. I am not sure what the issue was and I could not recreate it afterwards.

    But I am still not able to perform DMA transfer of  more than 63KB to L2SRAM (from the starting address:0x10800000). If I try to transfer more than that, the data in L2 memory region is erroneous. One more thing to note is that I could transfer 63KB of data successfully to an arbitrary starting location like 0x10810000 in L2 memory region.

    I did not get a chance to check if CCS was doing auto go main. I will check that soon.

    Thanks a lot for your help.

    regards,

    Barath Ramesh

  • In addition, before setting the L2 cache size to zero, you should probably invoke Cache_wbInvAll() because that does not happen automatically (as far as I know).

  • Jonathan: Thanks. I just saw this in the C66x cache user’s guide(http://www.ti.com/lit/ug/sprugy8/sprugy8.pdf):

    “On cache size changes, C66x devices automatically writeback–invalidate cache before initializing it with the
    new size. In contrast, C64x devices required an explicit writeback–invalidate to be issued by the programmer
    (however, this is handled as part of the CSL function).”

    Barath: For the DMA transfer issue I'm thinking it would be best to post a new thread on the Multicore DSP forum.  To me this sounds like a device-related constraint/issue, and not a BIOS issue...

    Thanks,
    Scott