MPC5775B/E, Problem with D-Cache and asynchronous MC Exceptions from MPU

peter_vranken — Fri, 03 Jan 2020 17:59:52 GMT

Dear NXP Team,

Migrating an OS kernel from MPC5643L to MPC5775B/E, we face some issues
with D-cache and MPU. With respect to the kernel, these two are the major
difference between the two MCUs.

The core problem is the delayed MC exception from the MPU in case of a
forbidden store:

The MPU sits behind the cache and only protects the contents of the main
memory. The cache contents are however damaged by the store. For normal
process RAM there is a solution: The IVOR #1 handler reads the target
address of the failing store from the MPU and issues a cache block
invalidation instruction (dcbi, icbi) at that address. This makes the
temporarily bad memory contents be replaced by the still correct,
undamaged main memory contents on next use.

By appropriate synchronization instructions, we can ensure that all of
this repair is safely completed prior to the next context switch, i.e.
another process may have damaged data for a short while but it won't
become active during this critical period of time.

Situation is worse for OS data. Like in most code samples, we hold e.g.
the External Interrupt vector table in RAM. If an External Interrupt
appears after a process has issued a forbidden store into the table but
before the MPU has raised the MC exception, thus before the IVOR #4
handler could repair the cache contents, then the read and used interrupt
address would be wrong and the code would crash.

We have configured the cache as write-through for all of the RAM.

Following (undesired) solutions are known:

* We can put all sensitive OS data into an MMU protected memory section.
MMU exceptions are raised synchronously and don't cause any headache.
Drawback: The MMU can only control memory chunks of power-of-two size.
We would loose a significant amount of RAM because of the alignment of
subsequent data sections
* We can turn off the store buffers to minimize the delay of the MC
exception from the MPU. (However, it is unclear if this would be enough
without even setting the guard bit.) Drawback: Significant performance
loss

Would you know more solutions? In particular, is there a possibility to
hinder the D cache from caching written data according to this idea: A
store at a cached address wouldn't change the cache block contents
immediately but invalidate the block so that subsequent reads would force
a cache line fill from the (protected, undamaged) main memory instead of
returning the illicitly overwritten cache block contents?

Kind regards

Peter

Re: MPC5775B/E, Problem with D-Cache and asynchronous MC Exceptions from MPU

lukaszadrapa — Mon, 06 Jan 2020 10:51:22 GMT

Hi Peter,

there's one more option - you can put sensitive data to certain RAM area which will be configured as cache inhibited by MMU. It will slightly affect the performance but I think this is the best solution.

By the way, this is much more easier on other MPC57xx devices which have CMPU (core MPU) and SMPU (system MPU), so access can be disabled directly in the core.

Regards,

Lukas

Re: MPC5775B/E, Problem with D-Cache and asynchronous MC Exceptions from MPU

peter_vranken — Mon, 27 Jan 2020 22:03:37 GMT

Thanks, Lukas, for your confirmation. Changing the MCU is of course not done just like that. However, meanwhile the SW is migrated and running stably. I've summarized the made experiences in a new thread, see https://community.nxp.com/message/1260631

MPC5xxx中的主题 Re: MPC5775B/E, Problem with D-Cache and asynchronous MC Exceptions from MPU

MPC5775B/E, Problem with D-Cache and asynchronous MC Exceptions from MPU

Re: MPC5775B/E, Problem with D-Cache and asynchronous MC Exceptions from MPU

Re: MPC5775B/E, Problem with D-Cache and asynchronous MC Exceptions from MPU