• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 1381 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.

RM57 Data Cache Flush / Clean

Christian Herget
Expert 6985 points


Hi,

I have a customer who likes to download an user application program and program it into the on-chip flash.

Because of the cache the instruction cache needs to be invalidated after the program was written to the flash memory. To be able to access data which is in the new user application also the data cache has to be invalidated, but just invalidating the entire data cache might cause issues as dirty cache lines will get discarded.

So my understanding is that the entire data cache has to be cleaned prior to invalidating it to ensure, that dirty cache lines will be written back to the memories (mainly SRAM).

I found a routine for doing this in the ARM Architecture Reference Manual, in the section B2.2.4 Cache maintenance functionality under Example code for cache maintenance operations. The same routine was also posted in e2e.ti.com/.../1753762.

  • Am I right that the data cache has to be explicitly cleaned before invalidating or disabling it to ensure that dirty cache lines are written back to the memories?
  • Am I right that a DSB instruction doesn't ensure that dirty cache lines are written back to the memories?

Thanks,
Christian

  • 0
    TI__Guru 72500 points
    • Am I right that the data cache has to be explicitly cleaned before invalidating or disabling it to ensure that dirty cache lines are written back to the memories?

    That depends. If you use write through instead of write back, the L2 SRAM stays current. Also when switching from a boot loader to an application, are you depending on the value of variables in RAM?

    • Am I right that a DSB instruction doesn't ensure that dirty cache lines are written back to the memories?

    You are correct, the data synchronization barrier does not flush the cache.

  • 0 in reply to Bob Crosby
    TI__Expert 6985 points
    Hi Bob,

    Thanks for the answer and confirming my understanding.

    The use case isn't a bootloader but it is the usage of CoDeSys which acts as a Runtime System, where User Applications can be downloaded and then executed in this environment. So the user isn't simply switching from one application to another, instead a "new part" gets added to the application. This means that they are dependent on the state of variables before the download of the User Application, but they are in a sort of Debug / Maintenance mode and performance isn't that critical so in theory they can effort running routine to clean the cache.

    I will discuss with them what makes more sense, to configure the cached RAM ranges as Write Through or to run a routine to clean them.

    Thanks,
    Christian