Hi,
I have a problem with MPC5566.
When I'm trying to invalidate the L1 cache memory using CFI bit in L1CSR0 register, it always fails (Rise of CABT bit) when an external interrupt is pending.
(Even when the cache is empty).
If I acknowledge the interrupt by reading IACKR register (and clearing the external IT pending bit in EISR register), the cache invalidation works fine again.
It is quite annoying as my cache invalidation can be in a decrementer interrupt that has to be processed before the external IRQ.
Can someone confirm that cache invalidation is impossible in this specific case ? Have you a workaround ?
Thanks.
Best regards,
Guillaume Chevillot
Solved! Go to Solution.
I finally manage to get an answer to this point. It is in the MPC5566 chip errata :
http://www.freescale.com/files/32bit/doc/errata/MPC55660CE.pdf
The e1031 explains that the problem is known and give a workaround proposal.
Quoting core RM:
“During the process of performing the invalidation, a cache does not respond to accesses that are not snoop accesses and remains busy. Interrupts may still be recognized and processed, potentially aborting the invalidation operation.”
Steps to configure the cache:
Thank you for your answer.
Quoting core RM:
“During the process of performing the invalidation, a cache does not respond to accesses that are not snoop accesses and remains busy. Interrupts may still be recognized and processed, potentially aborting the invalidation operation.”
RTFM ! ^^
Indeed, I was looking in MPC5566RM but not in E200Z6_RM.
But the manual sentence is not very explicit: "potentially aborting". In my case, it is systematic and with an interrupt than is not processed (just pending).
Indeed, from the core point of view, external IT are disabled (MSR[EE] = 0). Only, the interrupt controller (which is not part of the core) shall see it.
Steps to configure the cache:
- Software must ensure that any prior invalidation of the cache is completed
- Check L1CSR0[CABT]. If it is set, wait until complete.
I do exactly these steps, except for step one. Quoting RM about CABT:
"This bit is set by hardware on an aborted condition, and will remain set until cleared by software writing 0 to this bit location."
So, I do not think you should wait until it is cleared.
I finally manage to get an answer to this point. It is in the MPC5566 chip errata :
http://www.freescale.com/files/32bit/doc/errata/MPC55660CE.pdf
The e1031 explains that the problem is known and give a workaround proposal.