• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 1820 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Problem in accessing variable on Share RAM on OMAP L138

durga temp
Intellectual 435 points

Other Parts Discussed in Thread: OMAPL138, SYSBIOS

Hi,

I am trying to share a variable declared on shared RAM between ARM and DSP on OMAPL138.
Here variable always points to 0 on DSP.

Details:
ARM:
uint32_t *SharedValue = (uint32_t *)(0x8001FCC0)


DSP: SYS/BIOS
volatile uint32_t *SharedValue = (uint32_t *)(0x8001FCC0)

taskMain()
{
 System_printf("hello");
 CurrentValue = *SharedValue;
}

I have declared a variable on shared RAM on both ARM and DSP as a global variable.
ARM side I am writing to this value in an ISR.
DSP side SYS/BIOS is running and in one of the tasks I am reading this sharedValue.
Thie value always points to 0.

I have put breakpoint on ARM and I can see value getting updated in memory in ARM.

But on DSP, if I put a breakpoint say on line System_printf("Hello") and if I check memory for the address 0x8001FCC0, it shows the updated value.
But when the line CurrentValue = *SharedValue is executed, the value of 0x8001FCC0 in memory becomes 0 and I get 0 in CurrentValue.

What could be wrong?

thanks, Durga

  • 0
    TI__Genius 17355 points

    Durga,

    This sounds like it could be a simple cache coherency issue.  If you have the data cache enabled on either or both of the cores, you will likely need to make sure that the cache contents actually make it to memory on the ARM (cache writeback) and that the DSP will go to memory instead of the cache to get the value (cache invalidate).

    This is where I would start my investigation.

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Intellectual 435 points

    Hi Daniel,

    Thanks for the reply. I used Cache_inv function as given in section 6.4.1 of SYS/BIOS v6.x User guide.
    With this I am able to see the updated values on DSP side.

    #include <ti/sysbios/hal/Cache.h>
    Cache_inv(Ptr blockPtr, SizeT byteCnt, Bits16 type, Bool wait);

    Ex: For example to invalidate the entire shared RAM from L1 Data cache use following.
    Cache_inv((uint32_t *)0x80000000, 0x00020000, 0x2 ,1);

    One small thing. SYS/BIOS user guide tells Cache_inv(blockPtr, byteCnt, wait). type parameter is not included and it does not explain the parameters in detail.
    I found details in "C:\Program Files\Texas Instruments\bios_6_30_02_42\packages\ti\sysbios\hal\Cache.c" and "C:\Program Files\Texas Instruments\bios_6_30_02_42\packages\ti\sysbios\interfaces\ICache.xdc".

    Please correct me if I am wrong.

    thanks, Durga

  • 0 in reply to durga temp
    Intellectual 435 points

    Hi,

    As per my understanding, if the variable is declared as volatile, the changed value should be updated on the DSP.
    Then why we need to do cache invalidation?

    Also I see the same problem on ARM. The value updated on shared RAM by DSP is not reflected at ARM.
    I have searched for cache invalidation and I see following in ARM 926 TRM (section 2.3.8).

    Invalidate DCache SBZ MCR p15, 0, <Rd>, c7, c6, 0

    I have used following before checking the variable at ARM, but this is not working.
    asm(" MCR p15,#0,R15,c7,c6,#0");

    Please reply.

  • 0 in reply to durga temp
    TI__Genius 17355 points

    durga temp said:
    As per my understanding, if the variable is declared as volatile, the changed value should be updated on the DSP.
    Then why we need to do cache invalidation?

    This is not correct.  The C programming language doesn't know anything about the cache or memory architecture of the core on which a compiled program will run. Volatile does tell the C compiler that a memory location may change by some entity other than the program, so that the C compiler will not be able to optimize away accesses to that memory location. But on a CPU with a cache enabled, that memory access will pass through the cache architecture, and making sure that the data gets back to shared memory so that both cores can get to it is the job of the programmer/application author. In other words, you have to manage the cache on any core with cache enabled.

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Intellectual 435 points

    Thank you for the reply.
    And regarding the problem with accessing DSP changed data on ARM, I used cache_wb function at DSP. This solved the problem.
    thanks, Durga