• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 120 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS570LC43x reconfiguring MPU cache settings when switching contexts

Rama Alamleh
Prodigy 10 points

Hello, we are currently working on a project that involves using the TMS570LC43x microcontroller with a bare-metal software. This software employs a simple scheduling mechanism with two execution contexts: Code A, which runs in a periodic interrupt handler, and Code B, which executes in the background asynchronously to Code A. Our goal is to optimize the performance of Code A by enabling cache, while Code B work with cache disabled. There are sections of code shared between Code A and Code B, which will use a specific MPU region.

To achieve this, our plan is to reconfigure that shared code MPU region when switching to the Code A context, making it "MPU Cacheable." Then, when transitioning to Code B, we will reconfigure the MPU again to make it non-cacheable. 


However, we have a concern: Changing the settings of an MPU region from cached to non-cached might invalidate the related cache entries. Therefore, we are uncertain about the safety of this approach. We would like to know if there are any potential issues or considerations we should take into account before proceeding with this approach.

Thank you 



  • 0
    TI__Mastermind 46955 points

    HI Rama,

    We started working on your issue and will try to provide an update ASAP.

    --

    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    TI__Guru**** 187986 points

    Hi Rama,

    The MPU enables you to partition memory into regions and set individual attributes for each region. You can place code A (one or more functions or data sections) in an separate MPU region with cache enable. It should be fine since the cache content is not touched when running codeB. 

  • 0 in reply to QJ Wang
    Prodigy 10 points

    Hello QJ Wang,

    Thanks for the feedback. Maybe just a follow-up question.

    We will have a region with code shared between context A and B. The latter could be executed from both context. The plan is to adjust the MPU settings of that region as follows during runtime:
    1) Configure this MPU region as cacheable when transitioning from context B to A.
    2) Configure this MPU region as non-cacheable when transitioning from context A to B.

    Our question: when performing step 2), will the cache entries for this region be invalidated, or will they remain available for context A after step 1) is performed again?

    Thank you

  • 0 in reply to Rama Alamleh
    Guru 92251 points
    Rama Alamleh said:
    Our question: when performing step 2), will the cache entries for this region be invalidated, or will they remain available for context A after step 1) is performed again?

    Section 9.4. Attributes and cache maintenance of the ARM Cortex-R Series Programmer's Guide contains the following notes:

    Cache maintenance is required when the memory type, cacheability, or shareability attributes for a memory location are changed by reprogramming the MPU. Coherency in both Level-1 Instruction and Data caches and any Level-2 caches (if present) must then be restored by performing the following operations:
    - I-cache: invalidate all.
    - D-cache: clean and invalidate all.

    It is not necessary to disable and re-enable the MPU while restoring coherency in this way.

    An alternative strategy might be to invalidate by address (or clean and invalidate for the D-cache) for all addresses that used to be cacheable but now are not. However this will not usually result in improved performance.

    If you don't invalidate the I-cache in the shared code region when re-configuring the MPU region as non-cacheable then you might run into undefined behaviour.

    How big is the region of code shared between context A and B, and what is the performance impact of allowing the shared code region to be cached by context B?