• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 360 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.

OMAP L138 ARM memory setting problem

Jay Gowdy81418
Intellectual 810 points
Other Parts Discussed in Thread: SYSBIOS

We have been heavily using the DSP of an OMAP L138 in our projects, and have recently started to use the ARM core more, and are running into some strange problems.

We are using SYSBIOS 6.33.03.33 on both the ARM and the DSP.

The DSP sets a value in a memory location that the ARM is checking, and when the ARM detects that value is 1, it first resets the value to 0, and performs some actions.

I am finding that the ARM has to set the value to 0 at least 4 times before it actually "takes."   I am working around it, but it is quite perplexing.

The MMU and caching are enabled, but I have configured the MMU to have the shared memory location non-cacheable and non-bufferable, like it was a peripheral.  I verified in the generated configPkg/package/cfg/st_pe9.c file that the memory location really was being configured the way I thought, i.e., I see the line,

     mmuModule->tableBuf[3199] = 0xc7f00c12;

and the memory location lies in the 1M 0xc7f00000 segment.

The DSP side does a wb_inv after setting the shared location, and the DSP never sets it again, yet again, the ARM has to set the location to 0 several times.  Persistence pays off, and it gets set after a while, but that doesn't seem to be the way computers should act. I shouldn't have to nag them to set a memory location.

Anyone have any ideas of how to proceed in figuring this out?

  • 0
    Intellectual 810 points

    Grr.  I think I figured out my problem.  There was a process on my DSP that was doing a write back of nearby memory, but in the same cache line and it was writing back the "previous" values until I eventually caught it at the correct place in the DSP writeback/invalidation sequence.   My bad.

    One of the reasons that I panicked and started blaming mysterious ARM problems for my stupid mistake is that I have no idea where to start looking for documentation on things like ARM MMU and caching, and I'm feeling like a total noob when dealing with this thing.   So, can I change my question to this:  Where is a good documentation entry point for the A9 processor memory managment system that will answer questsion at roughly the same level of detail as the C6000 documents (like SPRU862b does for the C64x+).

  • 0 in reply to Jay Gowdy81418
    TI__Guru 64460 points

    Jay Gowdy81418 said:

    Where is a good documentation entry point for the A9 processor memory managment system that will answer questsion at roughly the same level of detail as the C6000 documents (like SPRU862b does for the C64x+).

    The first place I would suggest looking is on ARM's website for the ARM926EJ-S documentation.

    http://www.arm.com/products/processors/classic/arm9/arm926.php