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.

Fastcpy example, cache checking

Hi all,

I'd like to create my own xDAIS module which uses DMA. I'm using 'fastcpy' example (provided by TI) for getting in touch with DMAN3 features and figuring out how to implement DMA access  in an algorithm. This example is supposed to copy one region in the external memory to one region in the on-chip RAM and after that copy this region back to the external memory.

I compiled and debugged the project in CCS 4.2.3 and it works fine. What I wanted to do now is checking if the algorithm really copies the data to the on-chip memory. In FCPY_TI_alloc(), two working buffers are declared in the following way:

/* Request memory for working buffer 1 */

memTab[WORKBUF1].size = (params->srcLineLen) * (params->srcNumLines) *

 

sizeof (Char);

memTab[WORKBUF1].alignment = ALIGN_FOR_CACHE;

memTab[WORKBUF1].space = IALG_DARAM0;

memTab[WORKBUF1].attrs = IALG_SCRATCH;

 

 

/* Request memory for working buffer 2 */

memTab[WORKBUF2].size = (params->srcLineLen) * (params->srcNumLines) *

 

sizeof (Char);

memTab[WORKBUF2].alignment = ALIGN_FOR_CACHE;

memTab[WORKBUF2].space = IALG_DARAM0;

memTab[WORKBUF2].attrs = IALG_SCRATCH;

 

According to what I know, setting the variable memTab.space to IALG_DARAM0 makes the client application to allocate this buffer in the internal memory. However, I am not sure about this to be true.

I created a new CCS project using all the files used in 'fastcopy' example and tried to debug it to check the values of the pointers to worBuf1 and workBuf2. I did it this way because in the original project, 'fcpy_ti' is a library and I could not debug the execution of the function doCopy. I was surprised when I found that the values of the pointers worBuf1 and workBuf2 a region in the external memory (DDR2). In theory, they arre correctly allocated by DMAN3_grantDmaChannels() right?

 

Is there any reason why this could be happening?

 

Thanks a lot for your help

 

  • What device are you using?

  • Hello David,

    I am using DM6464 and I am compiling the project for working with Bios (my Bios version is 5.41). I forgot to mention that I am working with an evaluation version of CCS.

    Thank you and kind regards,

    Pablo,

  • I am not familiar with the DM6464 device. What version of Framework Components are you attempting to use ?

  • I am sorry, typing was wrong. My device is DM6446. Framework Components version is 2.26.0.1

  • No worries. I thought you might be referring to DM6446, but wanted to make sure.

    A couple of things to note:-

    - The fastcopytest.pjt includes fcpy_ti.pjt as a dependent project. You should be able to rebuild/link in a debug version of fcpy_ti.pjt and step through code and look through the workBufs etc.

    - You can switch on tracing for framework components, that gives you (as detailed as you want) information on what goes on inside the various FC libraries.  http://processors.wiki.ti.com/index.php/Trace_in_Framework_Components#Framework_Components_2.22_and_later_2.x_releases

    - Regarding your observations regarding the workBufs, in this particular example, the FC utility used to create/activate/delete the algorithm (called ALG) is simply an example. The real full-fledged framework component that is used to create algorithms and assign it the right kind of memory is called DSKT2. 

    http://processors.wiki.ti.com/index.php/Memory_management_in_XDAIS_with_DSKT2

    When creating an algorithm using DSKT2, you can make sure that the algorithm gets assigned memory in the space that it requests it (internal/external). It requires some configuration to make sure requests from algorithms are correctly satisfied, but the call flow is very straightforward and similar to the flow used with ALG in the fastcopy example.

  • Hi Gunjan,

    Tanks a lot for your help. I tried compiling fcpy_ti.pjt but I had the same results.

    Anyway, I've been reading some information about the DSKT2 that you recommended and I have decided to abandon 'fastcpy' example and try to move to DSKT2, given that is the usual memory management interface in new xDAIS modules.

    I have found some DMA examples in Framework Components folder related to DSKT2, but many of them are related to the use of semaphores and different threads. Could you recommend me some basic example with a similar functionality to 'fastcpy' example? I ask this because my aim is to read memory from DDR2, copy it to the internal memory, process it and then write it back to DDR2 memory.

    Thanks again for your help.

    Kind regards,

    Pablo

  • Unfortunately, there are no examples in this release that use both DSKT2 and DMAN3/ACPY3. However, migrating this example to use DSKT2 should be straightforward.

    Here's some information on how you can accomplish that:-

    1. In fcpy.h, replace all references to ALG_create/ALG_free with DSKT2 API calls:-

    Add the following:-

    #include <ti/sdo/fc/dskt2/dskt2.h>

    #define SCRATCHGROUPID 0 //Using arbitrary scratch group id of 0, only 1 algorithm is being created.

    Replace:-

       return((FCPY_Handle)ALG_create((IALG_Fxns *)fxns, NULL, (IALG_Params *)prms));

    and

        ALG_delete((ALG_Handle)handle);
    with:-
       return((FCPY_Handle)DSKT2_createAlg(SCRATCHGROUPID,(IALG_Fxns *)fxns, NULL, 
                (IALG_Params *)prms));
    and
        DSKT2_freeAlg(SCRATCHGROUPID, (ALG_Handle)handle);

     

    2. In dm6446_bios/fastcopytest.cfg file, you need to add a reference to DSKT2 as follows:-

    /* Program DSKT2 to use memory spaces defined in the tcf file */ 

    var DSKT2 = xdc.useModule("ti.sdo.fc.dskt2.DSKT2");

    DSKT2.ALLOW_EXTERNAL_SCRATCH = false;

    DSKT2.DARAM0 = "L1DHEAP"

    DSKT2.DARAM1 = "L1DHEAP"

    DSKT2.DARAM2 = "L1DHEAP"

    DSKT2.SARAM0 = "L1DHEAP"

    DSKT2.SARAM1 = "L1DHEAP"

    DSKT2.SARAM2 = "L1DHEAP"

    DSKT2.ESDATA = "EXTERNALHEAP"

    DSKT2.EPROG = "EXTERNALHEAP";

    DSKT2.DSKT2_HEAP = "EXTMEMHEAP";

    I  have tried this on a newer release (not on the one you are using), but I'm hoping the same changes will lead you to get  your program working successfully. Please let me know if you run into any issues and I can help you through them.

    Thanks,
    Gunjan. 

  • Hi Gunjan,

    It seems easier than I thought. Thanks a lot for your help again.

    I tried to add what you mentioned to my code but now I have a compilation error. Something like:

    ""

    I guessed that this sould be related to the dskt2 library, which was not included in my project. Thus, I added library dskt2.a64P to the File Search Path in the C/C++ Build options. Now the previous error dissapeared but I have some new ones...

    Severity and Description Path Resource Location Creation Time Id
    errors encountered during linking; "C:/Program Files (x86)/Texas Instruments/framework_components_2_26_00_01/examples/ti/sdo/fc/dman3/example s/fastcopy/dm6446_bios/debug/fastcopytest.out" not built  fastcopytest6446 line 0 1310375251505 80086
    unresolved symbol __DSKT_DARAM0, first referenced in C:/Program  fastcopytest6446 line 0 1310375251503 80077
    unresolved symbol __DSKT_DARAM1, first referenced in C:/Program  fastcopytest6446 line 0 1310375251503 80078
    unresolved symbol __DSKT_DARAM2, first referenced in C:/Program  fastcopytest6446 line 0 1310375251503 80079
    unresolved symbol __DSKT_EPROG, first referenced in C:/Program  fastcopytest6446 line 0 1310375251503 80080
    unresolved symbol __DSKT_ESDATA, first referenced in C:/Program  fastcopytest6446 line 0 1310375251503 80081
    unresolved symbol __DSKT_IPROG, first referenced in C:/Program  fastcopytest6446 line 0 1310375251503 80082
    unresolved symbol __DSKT_SARAM0, first referenced in C:/Program  fastcopytest6446 line 0 1310375251504 80083
    unresolved symbol __DSKT_SARAM1, first referenced in C:/Program  fastcopytest6446 line 0 1310375251504 80084
    unresolved symbol __DSKT_SARAM2, first referenced in C:/Program  fastcopytest6446 line 0 1310375251504 80085
    unresolved symbol __DSKT2_ALLOW_EXTERNAL_SCRATCH, first referenced in C:/Program  fastcopytest6446 line 0 1310375251502 80073
    unresolved symbol __DSKT2_DARAM_SCRATCH_SIZES, first referenced in C:/Program  fastcopytest6446 line 0 1310375251502 80074
    unresolved symbol __DSKT2_HEAP, first referenced in C:/Program  fastcopytest6446 line 0 1310375251502 80075
    unresolved symbol __DSKT2_SARAM_SCRATCH_SIZES, first referenced in C:/Program  fastcopytest6446 line 0 1310375251503 80076
    unresolved symbol _DSKT2_cacheWBInvFxn, first referenced in C:/Program  fastcopytest6446 line 0 1310375251502 80072

    I guess I am missing something, probably is a stupid mistake. Do you have any idea about what could be happening?

    Thanks a lot again Gunjan.

    Kind regards,

    Pablo Colodron

  • Sorry. I forgot to add the first compilation error. It was:

    Severity and Description Path Resource Location Creation Time Id
    unresolved symbol _DSKT2_createAlg, first referenced in C:/Program  fastcopytest6446 line 0 1310379806145 80087

     Thanks!

  • I may have missed out on some edits that you need to your dm6446_bios/fastcopytest.cmd file etc. I'm going to try these changes sometime this evening and will update this post accordingly.

     

  • I tried out the changes I suggested to you and I got the same errors. The issue is that this fastcopytest example is building with non-RTSC configuration. So the .cfg file is not being used.

    This means that all the configuration related information needs to be explicitly added to the "C" file and the ".cmd" file. (Note:- This information would get included automatically if building using rtsc/xdc).

    I'm attaching the files I had to change to get this project to build and run, the changes are minor. Here's a summary of my changes

    1. .cmd file -> Add assignment of heap names to DSKT2 variables

    2. tcf file -> Increase size of internal memory heap, since now DSKT2 will use it to create buffers  in internal memory (these would be generated due to configuration, if xdc  was used to build this example).

    3. fastcopytest.c file -> Define some arrays etc (these would be generated due to configuration, if xdc  was used to build this example).

    4. cfg file changes can be reverted back

    1104.fastcopytest-mods.zip.txt

  • Hi Gunjan,

    I thought it could be something related to that, because I figured out that the .cfg file was not being used. However, as I did't know the differences between RTSC configuration and non-RTSC I didn't know how to solve it.

    With your solution THE PROJECT WORKS FINE AND ALLOCATES THE BUFFERS IN THE INTERNAL MEMORY.

    You only attached fastcopytest.c but I assumed that the configuration parameters in .cmd are those described in DKT2 user's guide. I also increased the values of IRAM (to 0xc000) and L1DSRAM (to 0x1000). The execution of the algorithm works fine now, although there is a warning when executing DSKT2_createAlg:

    @0x00000000:[T:0x00000000] ti.sdo.fc.dskt2 - DSKT2_createAlg3> Scratch Memory requested by algorithm, but algActivate, algDeactivate functions not implemented.

    This is because the pointers to these functions are NULL, but the algorithm works fine anyway.

    Thank you very much for your perfect support. Many days would have passed before I could fix this by myself. What I'm going to try now is to compile this project for working with RTSC. Do you think this is feasible? I will try to get some support from ti.wiki and the book 'OMAP and DaVinci Software for Dummies'.

    If I wanted to use this algorith with Codec Engine, it should be necessary to buil it using RTSC configuration right?

     

    Thanks again and kind regards Gunjan!