Other Parts Discussed in Thread: OMAPL138
Tool/software: Code Composer Studio
Dear all,
we are using the OMAP L138/ DSP with a very fast task (125 us). We rely on that most of the functions in this task load only once from DDR RAM and reside in L2. Thus, we set the L2 Cache to 50% and linked some of the functions to L2 RAM. However, it was not possible to link all functions to L2, esp. there are many alternative functions which are selected by run-time configuration parameters.
I had the effect that a part of code involving a number of function calls with just some lines of effective code took 3 us - by linking one of them to L2, the time was reduced to below 500ns. I suppose this was caused by a cache performance or cache miss problem, but was not able wo prove this.
Is there a way to monitor cache hits/ cache misses during run-time?
Is there a "good practice" of reducing cache misses by using a certain link pattern?
Upon our configuration parameters, it would be possible on start-up to determine "n out of m" functions that are really needed with the actual configuration. We had the idea to build a memory management, copy the necessary functions there and call them by pointers. (I know the gcc overlay mechanism, but I think we cannot use it because we need "n out of m"). Has this already been done/ is there some hints or sample code?
Thanks for any hint
Alexander