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.

Incorrect Direct Memory Access while OMAPL138 ARM Core runs RTOS

Other Parts Discussed in Thread: OMAPL138

Hello OMAPL138 IPC RTOS or MMU experts,

To have IPC feature running on OMAPL138LCDK, I allocated memory address 0xC0000000 to 0xC0000100 for semaphore flags and for passing data between ARM and DSP cores, and IPC worked just fine.  However, when I started to use RTOS (with MMU enabled), I have following issue on CCSv5.5 debugger:

While debugging on ARM core under ‘CPU Memory View’ mode, only DSP core has correct access (read/write) to memory (0xC0000000 to 0xC0000100 for example).

While debugging on ARM core under ‘Physical Memory View’ mode, only ARM core has correct access to the same memory.

While debugging on DSP core, only DSP core has correct access to the same memory.

 

It seems to me ARM and DSP cores cannot work properly simultaneously, once RTOS runs on the ARM core (with MMU enabled).  Is there a way to get around this issue?  Or I have missed any thing here?  IPC supposes to work like before, when there was no RTOS, right?

Thank you!

YeuShyr

  • Hi,
    Are you running RTOS code on both cores ?
    Getting issues only when you enabled MMU on ARM core ?

    Are you using any TI example code or written by your own ?

    Could you please clarify, what do you mean by CPU Memory View and Physical Memory View?
  • Hello Titus,

    There is no RTOS on DSP core in all my cases, but there is a third-party RTOS code running on ARM core when the IPC failed.   So far, I am still trying to disable MMU but without success.  Thus, all conditions had MMU turned on, but then I had different outcomes from two following scenarios:

    1. IPC and DMA work perfectly for both ARM and DSP cores while there are have no RTOS running on either of them, with MMU enabled.

    2. IPC or DMA does not work (at ARM core) while RTOS running on ARM, with MMU enabled.

    In both cases, my OMAPL138 has both TI Starterware code and my own code on it.  

    Regarding 'CPU Memory View' and 'Physical Memory View', they are the two switches only showing at CCS Debugging mode's Memory Browser window as below:

    Thank you!

    YeuShyr

  • Hi YeuShyr,
    Thanks.
    I don't have any clue on this issue.
    I moving your post to our RTOS forum where you get exact solutions for your problem.
  • Before we go deep into RTOS, would you please check this issue that showing inconsistence between Memory Browser and Expressions windows?  For example, at address 0xC00001D0, the correct value should be 2.001, but the Expression windows shows 1.0. Why there is such difference?  If the emulation keeps going, the correct 2.001 will get refreshed by that incorrect value: 1.0, and an error occurs. Please advise, thank you!

    YeuShyr

  • YeuShyr,

    It looks to me that your are having a cache coherency issue. This happens when a value is read from memory into the CPU cache, at which point the CPU will continue to see the cached value at the given memory location. If the data in memory is changed by the other processor, your local CPU will not see this change. It will continue to see the old value in the cache.

    In the CCS memory browser, when you select 'CPU Memory View' you are looking through the cache. If the memory address has been loaded into the cache, the CPU will see the cached value. When you select 'Physical Memory View', then you are bypassing the cache and looking directly at the memory.

    I suggest you disable cache for the memory used by your IPC code. Then your CPU will always see the current value in memory.

    ~Ramsey

  • Hi Ramsey,

    You are right. As soon I added following two subroutines in system initialization, my IPC started to work properly.

    CP15ICacheDisable();
    CP15DCacheDisable();

    Thank you and Titus so much!

    YeuShyr
  • Hi YeuShyr,
    Sounds good.
    Glad to hear.
    Thanks for your update.