MCF5484 branch/instruction cache coherency problem

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

MCF5484 branch/instruction cache coherency problem

534 Views
achimd
Contributor I

I think i have a coherency problem that i can not fully understand.

 

At startup our application is running directly from the flash. While running from flash the instruction and branch cache are enabled to speed up the booting stage.

After enabling the caches we perform a ram test that is writing and reading from every ram location of our external sdram (data cache is not enabled).

Then the external sdram is "initialized" to run our code from there. First the bss section is set to zero then the code is copied from flash to ram.

Directly after the exectution from flash is finished with calling the first function in the external sdram. At that point an illegal instruction excpetion occurs.

 

Debugging the code shows no illegal instruction at the first statement in the external ram. In fact the ram content is exactly as it should be.

When i change the pattern of the ram test to a valid statement (branch to the same address or rts), the program behaves as if the pattern is executed. So i guess that somehow the branch or instruction cache is holding information about the memory content that is present after executing the ram test but before the code copy took place. Could this be possible somehow?

 

Our code looks like this:

 

startup()

{

  // Init stuff

  ...

  EnableInstructionAndBranchCache();

  RamTest();

  InitBss();

  CopyCode();

  // until here every statement is executed in the flash

  FirstFunctionInRam();

}

 

RamTest, InitBss and CopyCode are basically read/write loops over the external ram.

 

Additionally if i add a hardware breakpoint the exception does not occur.

Labels (1)
0 Kudos
2 Replies

371 Views
TomE
Specialist II

You're right, it doesn't make sense.

You don't need to understand it to fix it. After any code copy you should flush the Data Cache (to force any cached data back to main memory) and then invalidate the Instruction Cache (so it will get fresh data). You'll also need to do whatever the branch target cache needs to clear it out.

Yes, by your description this shouldn't apply in your case as the RAM is uncached, but this "standard approach" to what you should do after copying code should fix it. Only if it doesn't you'll have a problem.

Somewhere in your code you must be enabling the caches on the RAM. If you're not enabling the data cache on it, then you probably should. Changing the cache (I assume by rewriting the ACRs) should probably only be done with the caches disabled, and then you should probably make sure you execute a "pipeline flush" before you enable them again.

Your breakpoint is doing that, which is probably why it works when you do that. Maybe your real problem is not flushing the pipeline after critical (cache and MMU) instructions.

"Pipeline Flush" is documented in the Programmer's Reference Manual, and also mentioned in "4.2.3 MMU Control Register (MMUCR)". The Coldfire "NOP" instruction does this.The "New NOP" is "TPF".

Tom

0 Kudos

371 Views
achimd
Contributor I

Yes i don't need to understand it to fix it. But if i do it that way im not exactly sure if the fix is correct or just some side effect solves the problem.

If i add a NOP after activating the branch and instruction cache the problem disapears as well. But as far as i know the MOVEC.L instruction to set the cacr or acr registers should already synchronize the pipeline.

0 Kudos