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.

RTOS/AM3359: Cache enable in EtherCAT application

Part Number: AM3359

Tool/software: TI-RTOS

Hello !

My configuration is the following one:

- Sitara ARM3359
- Code Composer Studio version CCS 6.1.2.00015
- SYS/BIOS 6.45.01.29 Real Time Operating System
- XDC Tool 3.32.00.06
- Compiler GNU v4.8.4 (Linaro)
- NDK 2.24.3.35
- Sysbios sdk 2.1.3.2
- software Texas Instrument ecat_appl with beckoff patch v5.11

In order to improve our code we need to make operations very fast.

So, we are investigating on using cache to improve the speed execution.

The MMU table is the following one:

SYS_MMU_ENTRY applMmuEntries[] =
{
    {(void *)0x08000000, SYS_MMU_CACHEABLE | SYS_MMU_BUFFERABLE},   //NOR - bufferable| Cacheable
    {(void *)0x08100000, SYS_MMU_CACHEABLE | SYS_MMU_BUFFERABLE},   //NOR -bufferable| Cacheable
    {(void *)0x08200000, SYS_MMU_CACHEABLE | SYS_MMU_BUFFERABLE},   //NOR - bufferable| Cacheable
    {(void *)0x48300000, 0},   //PWM - Non bufferable| Non Cacheable
    {(void *)0x48200000, 0},   //INTCPS,MPUSS - Non Bufferable| Non Cacheable
    {(void *)0x48100000, 0},   //I2C2,McSPI1,UART3,UART4,UART5, GPIO2,GPIO3,MMC1 - Non bufferable| Non Cacheable
    {(void *)0x48000000, 0},   //UART1,UART2,I2C1,McSPI0,McASP0 CFG,McASP1 CFG,DMTIMER,GPIO1 -Non bufferable| Non Cacheable
    {(void *)0x44E00000, 0},   //Clock Module, PRM, GPIO0, UART0, I2C0, - Non bufferable| Non Cacheable
    {(void *)0x4A300000, SYS_MMU_SHAREABLE | SYS_MMU_BUFFERABLE},   //PRUSS1 -Bufferable| Non Cacheable | Shareable
    {(void *)0x49000000, 0},   //EDMA3 - Non bufferable| Non Cacheable
    {(void *)0x4A000000, 0},   //L4 FAST CFG- Non bufferable| Non Cacheable
    {(void *)0x4A100000, 0},   //CPSW - Non bufferable| Non Cacheable
    {(void *)0xFFFFFFFF, 0xFFFFFFFF}
};

and in the tiescutils.c file whe hae the following initialisation:

    SDKMMUInit(applMmuEntries);   // needed first

    Cache_lock((Ptr)0x80000000, 0x8000);
    Cache_wait();
    Cache_lock((Ptr)0x80008000, 0x8000);
    Cache_wait();
    Cache_lock((Ptr)0x80010000, 0x8000);
    Cache_wait();
    Cache_lock((Ptr)0x80018000, 0x8000);
    Cache_wait();
    Cache_lock((Ptr)0x80020000, 0x8000);
    Cache_wait();
    Cache_lock((Ptr)0x80028000, 0x8000);
    Cache_wait();
    Cache_lock((Ptr)0x80030000, 0x8000);
    Cache_wait();

    pruIcss1Handle = (PRUICSS_Handle)malloc(sizeof(PRUICSS_Config));
    pruIcss1Handle->object = (PRUICSS_V1_Object *)malloc(sizeof(
                                 PRUICSS_V1_Object));
    pruIcss1Handle->hwAttrs = (PRUICSS_HwAttrs *)malloc(sizeof(
                                  PRUICSS_HwAttrs));

.......................................

BIOS_start();

before starting the BIOS, we tried to enable cache with the following code:

    Cache_enable(Cache_Type_L2 );    
     Cache_enable(Cache_Type_L1P );   
     Cache_enable(Cache_Type_L1D );  

We have make measures with a scope connected on a sitara output to see if the speed is improved but nothing seems to change !

We don't know if the cache is really enable and, if not,  how to do it !

Can someone help us, please ?

Thanks a lot !

Laurence
 

 

  • The RTOS team have been notified. They will respond here.
  • Laurence,

    usually cache for DDR is enabled per default in our examples. Do you run your code from DDR? With the above code you may even lock major parts in L2 cache anyway. As far as I know this requires enabled cache.
    To check for cache/MMU status you can use the ROV tool in CCS. Also UIA may help to log task timing and display in graphical view. Usually very helpful to get a quick idea of idle percentage.

    Regards,
  • Hello Frank !

    Thanks for your answer.

    To answer your first question: yes, we are running in DDR3 !

    If we use the ROV tool, we have the following informations:

    Can you tell me what is the signification of that (I don't really understand...)

    Is that mean that my cache is enable ?

    Nevertheless, I try to comment the argument SYS_MMU_CACHEABLE in the MMU table and nothing seems to change in my scope measures !

    Can you explain me a little bit how it works, please ?

    Thanks a lot !

    Laurence

  • Hi Laurence,

    your picture didn't make it onto the forum...

    Anyway if you refer to this entries:
    {(void *)0x08000000, SYS_MMU_CACHEABLE | SYS_MMU_BUFFERABLE}, //NOR - bufferable| Cacheable
    ========== not 0x8000 0000...
    {(void *)0x08100000, SYS_MMU_CACHEABLE | SYS_MMU_BUFFERABLE}, //NOR -bufferable| Cacheable
    {(void *)0x08200000, SYS_MMU_CACHEABLE | SYS_MMU_BUFFERABLE}, //NOR - bufferable| Cacheable
    then this is not changing DDR cache. You are here in the NOR address range of the ICE board...
    DDR options are usually configured by the base target definition.
    Above table only adds additional MMU config for the application.

    Regards,
  • Yes, you are right !

    The MMU table only concerns the NOR !

    Anyway, our code is larger than yours and is stocked in DDR3 until the adress: 0x800B8000.

    So, we have to configure all this memory cache, right ?

    We have added the following lines in the tiescutils.c file:

       Cache_lock((Ptr)0x80000000, 0x8000);

       Cache_wait();

       Cache_lock((Ptr)0x80008000, 0x8000);

       Cache_wait();

       Cache_lock((Ptr)0x80010000, 0x8000);

       Cache_wait();

      .........

       Cache_lock((Ptr)0x800A0000, 0x8000);

       Cache_wait();

       Cache_lock((Ptr)0x800A8000, 0x8000);

       Cache_wait();

       Cache_lock((Ptr)0x800B0000, 0x8000);

       Cache_wait();

       Cache_lock((Ptr)0x800B8000, 0x8000);

       Cache_wait();

    I think it is not enough to configure the DDR cache !

    In the ROV window, we only see the former address: ( see ROV file)

    So, our adress are not on the window.

    And you say that DDR configuration is made in the base target definition: where it is ?

    Thanks

     

  • Laurence,

    I think you misunderstand the locking feature... I wonder your program is working at all.
    Cache means there is memory that will be dynamically loaded from DDR so it can execute faster. But the size is limited and there are only 8x 32kb on the device. When you lock mem into the cache then there is no way to execute anything else from cache. In addition L2 if for instructions and data. So you should never lock all 8 blocks.
    Please remove ANY locking code for now as it doesn't make sense right now. You may later lock critical sections (such as ISRs) to optimise. But you will not be able to lock all of your program. But you can cache enable all of DDR. See the MMU section in ROV.

    Regards,
    Frank
  • Yes ! I understand what you say !
    So I have to remove all my locks because They doesn't mean anything.
    Then put my critical code in specific portion of DDR and only lock this specific portion !
    I wonder another thning: as I work in c++ is it possible to put the heap section in secure zone ?
    I will try to do what I say and give the feedback after, right ?
    thanks a lot
    Laurence