MCF5485 instruction cache enable

[guiserix]

Hello

I'm trying to enable the instruction cache on my software running on MCF5485 coldfire to speed up operation.

When I run my software using codewarrior debug in SDRAM, it 's working well but when i want to load my software to run in flash nothing is working and the program is stuck.

So I've created a very simple program switch on LED wait switch off LED and for the moment same result.

I enable the cache using thee following:

move.l #0x00008100, D0

movec D0,CACR

Can you please help me?

Original Attachment has been moved to: Hello_FL.zip

[TomE]

I'm not going to read your code.

> When I run my software using codewarrior debug in SDRAM, it 's working well but when i want to load my

> software to run in flash nothing is working and the program is stuck.

Has that got anything to do with the Cache? Does it NEVER work in FLASH or only not work in FLASH when you try to enable the Cache? I'm guessing the latter, but it isn't clear in your post.

> and for the moment same result.

You may have two completely separate problems here. As the MCF5385 doesn't have internal FLASH you must be using external ones on the Flexbus.

You're setting the CACR to 0x8100. That enables and invalidates it. Good. You're also lucky to be using a CPU with separate instruction and data caches. If/when you go to enable the Data Cache (because it does make another big difference in CPU speed) you have to set up cache inhibited regions for MBAR (as noted in "9.3.1 Module Base Address Register (MBAR)") and talking to all DMA-based peripherals gets very tricky.

If it fails to work in FLASH when you enable the Cache, I've seen that before.

When the Cache is disabled the external memory accesses (to FLASH) are single words at a time. When you enable the cache it tries to perform a "burst line fill" memory cycle. If your Flexbus controller setup got the burst mode wrong it would explain your problem as it would read "garbage" into the cache. Since you can't read the cache back from the debugger you can't see what went wrong. Since you're not using the Data Cache you can't inspect the data either.

Check the burst-mode programming for the Flash Chip Select in the Flexbus controller. You may want to try and disable any burst mode (if you can) to see if it fixes the problem. Otherwise see how it is programmed and model the memory cycles and see if they're "legal" according to the Flash data sheet. If all else fails, put an oscilloscope on the Flexbus to see what you're doing wrong. That should show the difference between "Cache Enabled" and "Cache Disabled" cycles and lead to a solution.

You can test this by writing some simple code that runs in SDRAM and copies code from FLASH into SRAM (NOT SDRAM). Have your code enable and flush the DATA CACHE, copy from FLASH to SRAM (which will use a line-burst-read), disable the cache and then drop into the debugger to read SRAM to see what the burst read read from the FLASH. You want to read from an area in FLASH that has a known data pattern in it.

Tom

[guiserix]

You were correct the problem was indeed in the flash flexbus configuration : all the burst functions were disabled.

So now the instruction cache is working. I also successfully enabled the branch cache.

But I tried to enable the data cache and for the moment, it's not working.

It's my first time dealing with cache problem and seems like you are a cache expert so maybe you have a solution for this problem.

I wrote the following code:

move.l #__MBAR, D0  // to inhibit cache for MBAR registers

movec D0, ACR0

move.l #0x810C8100, D0

movec D0, CACR

When i execute the following code on my application using FREERTOS, it starts correctly.

But after my first psc access the system is stuck in PSC task.

Is there anything wrong with my cache configuration?

[TomE]

> Is there anything wrong with my cache configuration?

Only everything. What about the other 24 bits in ACR0 you haven't set? They consist of 7 fields:

- ADMSK is set to zero, which might be what you want, but you should check. How big is the MBAR region?

- E is set to zero so the register is completely DISABLED.

- S is set to zero which means it only works for "USER" code, you need "Both".

- AMM is set to zero which means 16M regions. Probably OK, but check this.

- CM is set to zero which ENABLES the cache for this region, the opposite of what you intended.

- SP is set to zero, which is OK.

- W is set to zero, which is OK.

If you get that right, Ethernet, USB and anything using DMA won't work at all because these devices are on the OTHER side of the cache, so they will read and write different data to what the CPU gets out of its caches. Some CPUs have "cache snooping" to fix this problem, but these ones don't:

7.7 Cache Overview

The cache module does not implement bus snooping; cache coherency with other possible bus masters
must be maintained in software.

You either have to put all of the Data and Control structures into uncached memory, or you have to rewrite all drivers to flush and invalidate the buffer regions whenever the CPU writes them or goes to read them. This is a huge amount of complicated and bug-ridden work if it hasn't been handled already by whoever wrote your OS and drivers.

If you can, you should use and/or buy a working OS for the chip that has already got all of this working.

Tom