[MCF54450] Enabling D-Cache && I-Cache 'crashes' the processor

[laurent_mode]

Hi Everyone,

I've been trying to get the D&I cache working on a custom board we made, and all I get is the processor 'crashing' !

The custom board is mainly designed after the MCF54455EVB demonstration board, uses the same DDR2 chips, only difference is we have a slightly bigger flash boot chip and we run it of a 24Mhz xtal, not a 33Mhz one.

The board runs fine (from boot flash, from ddr, from static ram) until I try to enable the processor cache (CACR is configured to enable caching but disabling I & D cache by default. ACRx are then used to enable caching of the bootrom and the ddr).

As soon as I do that, the processor either stops, or crashes or even resets itself. I tried to enable to data cache only, to cache the bootrom or the ddr only, it just crashes. If I am in the middle of transmitting to the UART, the UART output goes wild and just transmits random piece of garbage.

It even does that If the code is running in the internal static ram which is cache-inhibited anyway !!!

If I am running the EXACT SAME CODE (but for the PLL configuration) on the demonstration board it runs just fine.

I've trippled check the DDR2 and FlexBus timings against the chips' datasheets, nothing wrong here.

The code I am running does nothing more than transmitting to the UART and performing a memory test on the DDR (walking ones and son on).  it is small enough to fit in the static ram.

Is there any difference between the 54455 & 54450 die that could cause that ? could it be an external hardware issue ?

Any hint would be greatly appreciated, I'm feeling a bit stuck now.

Regards,
Laurent.

[McuG]

Were you able to find the solution to this ( we are facing a similar problem)?

[laurent_mode]

Hi McuG

The root of our problem was not the cache, but the PLL ...

Here's what the device's errata says :

4 PLL Loss-of-lock at Large Voltage Differentials
4.1 Description
There is a sensitivity to large differentials in IVDD and EVDD/OSCVDD in the PLL feedback path. This
sensitivity can cause the PLL to lose lock and, in some cases, fail to generate output clocks.
Table 2. Available SRAM Access Modes
V BDE Description
0 0 No SRAM accesses allowed
1 0 Only core accesses allowed
0 1 Only backdoor accesses allowed.
Note: The core can still access the SRAM backdoor port
via the crossbar switch
MCF5445x Device Errata, Rev. 1
PLL Loss-of-lock at Large Voltage Differentials
4 Freescale Semiconductor
4.2 Workaround
There are two requirements that must be met to avoid this errata:
1. Disable the PLL's loss-of-lock feature by setting bit 4 in the PLL status register
(MCF_PLL_PSR |= 0x10).
2. Ensure that the IVDD, EVDD, and OSCVDD supplies are within the following limits:
4.3 Status
Will be fixed in next device revision.

Although it does not seem related to the cache, it is, once we implemented the work around our cache problems where gone !

[McuG]

Thank you for the quick reply. It pointed me in teh right direction: burst access to teh DDR.

I’ve quickly tried the PLL fix as suggested, but it seems that the PLL Status register has been changed in mask 2M22H and bit 4 is not available anymore.  We’ve looked at the hardware connections for the DDR and they seem to be fine.

One thing that is worth mentioning is that on our board,  the tracks that connect the DDR are rather short (less than an inch), and as mentioned in another thread, DDR initialization parameters might need some tweaking in order to have  optimal results. Tried the RD_LAT 5 (as mentioned  in another thread) in the SDRAM configuration register, but without any magical results.

While in the  process of checking the DDR initialization values, I found that the SDCFG2 register settings were not properly calculated. I updated the values , and things got better. When new values for SDCFG2 were used and the RD_LAT 5 was set, one of the problems that we had got fixed (Ethernet was sending some corrupted packets before), but cache is not working yet. I am going to keep looking at the differences to see if i missed something else.

The developed  board based on the MCF54451 and a MT46V32M16 DDR ram  The code is based on MQX 3.6.1 (ported the 54455 for the hardware differences).

In the current stage I am able to run MQX from the onboard flash/DDR (without any debugger initialization)  with the cache disabled.  I am able to run the same code on the M54451EVB with the cache enabled.  MCU’s on both boards are mask 2M22H (some of the errata items should not apply to this version ). 

[bramey]

Did you find a resolution to your memory/cache problem?  We have a very similar problem on our board using the 54455

thanks

brian

[TomE]

> Were you able to find the solution to this ( we are facing a similar problem)?

Good response on the other thread (the swapping of the address bits).

Enabling the cache allows burst-mode reads and writes to the memory. Problems in the hardware design or programming related to burst mode is one of the things that the cache can show up. For instance, if using 16-bit DRAM, but with code assuming 32-bit DRAM it is possible that the "burst length" programmed into the DRAM is only half of what the memory controller is using.

The cache (or caches) have to be FLUSHED before they are enabled. CPU reset doesn't clear them. If you haven't copied all of the code from the development board, or are using sample code that relies on some debugger initialisation (that you didn't know about), then this step might be missing in your code.

The problem where even code in SRAM didn't work may have been because the SRAM wasn't enabled for direct access. It defaults to "access via the back door" and these accesses are both slow and possibly cacheable.

Tom