MPC5566 Unable to flash invalidate cache when external IRQ is pending

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MPC5566 Unable to flash invalidate cache when external IRQ is pending

Jump to solution
1,633 Views
guillaumechevil
Contributor II

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

Labels (1)
0 Kudos
1 Solution
1,294 Views
guillaumechevil
Contributor II

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.

View solution in original post

0 Kudos
3 Replies
1,294 Views
davidtosenovjan
NXP TechSupport
NXP TechSupport

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:

    1. Software must ensure that any prior invalidation of the cache is completed
      • Check L1CSR0[CABT]. If it is set, wait until complete.
    2. Software must then invalidate the cache by setting L1CSR0[CINV] = 1
      • Reset does not invalidate the cache automatically.
    3. Once set, hardware clears L1CSR0[CINV] after approx. 134 CPU cycles
      • During this time, CPU waits for cache invalidation to complete.  Code is not executed.
      • Software should poll  L1CSR0[CINV] bit until it is cleared.
      • This works with the cache disabled or enabled
    4. Software executes msync and isync instructions
    5. Software then enables cache by setting L1CSR0[CE] = 1
    6. Software must then set Cache Write Mode,
      • Write-through Mode: L1CSR0[CWM] = 0
      • Copyback Mode: L1CSR0[CWM] = 1
      • (Default CWM is write-through)
    7. In the MMU, the TLB[I] (Cache inhibited) bit must be cleared for memory areas that are to be cached
    8. Valid bits and lock bits are cleared during invalidation
    9. Tag parity is set during invalidation

1,294 Views
guillaumechevil
Contributor II

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:

    1. 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.

0 Kudos
1,295 Views
guillaumechevil
Contributor II

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.

0 Kudos