Were you able to find the solution to this ( we are facing a similar problem)?
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 !
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 ).
Did you find a resolution to your memory/cache problem? We have a very similar problem on our board using the 54455
thanks
brian
> 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