MPC5566 Unable to flash invalidate cache when external IRQ is pending

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

MPC5566 Unable to flash invalidate cache when external IRQ is pending

跳至解决方案
2,223 次查看
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

标签 (1)
0 项奖励
回复
1 解答
1,884 次查看
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 项奖励
回复
3 回复数
1,884 次查看
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,884 次查看
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 项奖励
回复
1,885 次查看
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 项奖励
回复