I am not familiar with any of these specific files, but will try to
answer some from a general perspective:
cache - correct, cache is disabled out of reset. To enable cache you
have to write the L1CSR0 to turn on the cache, plus you have to make
specific memory cachable within its MMU setting - note that some of the
MMU settings already be cachable out of reset. (1) Why would you want
to enable cache - cache is only one access cycle so your code will
executes faster. Note that Idd will increase when you use the cache.
(2) There is no need to check L1CFG0 - this is constant data for each
part in the family and merely confirms the size of the cache.
FMPLL - this allows you to set you sysclk to your desired rate. (1)
Changing PREDIV and MFD forces the PLL to re-lock which means the
frequency swings either side of the final locking frequency. If you are
setting the max sysclk i.e. 132, the sysclk would swing above that value
briefly during the locking phase and its possible the part could fail if
the frequency is too high. To prevent this, you get it to lock with the
post divider (RFD) at +1 (i.e. divide by 2) i.e. 66MHz so that max freq
is not violated. Once the PLL has locked, you set RFD to desired value
to get desired frequency (i.e. 132M) and since the post divider is
outside of the VCO loop, there is no relocking or overshoot during this
second step. (2) can't think of a good reason why cache is inhibited
here.
SRAM ECC - you HAVE to init the SRAM after a power up (not required
after a RESET) by performing a 64-bit write. Failing to do so means
that the 72-bit SRAM word (64-bit data plus 8-bit ECC checksum) has
incorrect checksum and any accesses other than a 64-bit write will cause
it to fail and generate an exception or bus error. Not initialising the
SRAM doesn't mean bits will flip, it means you simply cannot read or
write the SRAM.
cfg_FLASH - the Flash comes out of reset with maximum wait-states.
Refer to the ref manual, but even at max sysclk frequency, maximum wait
states are not required, so to get improved performance from the flash,
you would set the minimum possible wait-states for your operating
frequency.
cfg_MMU - I'm not familiar with the details of the files but reasons for
changing MMU would be to enable cache or VLE for specific regions, to
set memory blocks for external memory or even to re-arrange the entire
memory map to suit your own prefferential memory map if so desired.
- Allan
________________________________
From:
MPC500@... [mailto:
MPC500@...] On Behalf
Of stevenaschroeder
Sent: Wednesday, January 07, 2009 11:24 AM
To:
MPC500@...
Subject: [MPC500] AN2789 - MPC5500 Configuration and Initialization
I have been experimenting with Freescales, MPC5500 initialization code
and wonder if someone could clarify a few things for me. Running down
the list of configuration functions:
cfg_CACHE - If I understand, the cache is not active out of reset, so
this simply enables it. (1) Why wouldn't you want to do this? (2) If
you know the particular part has cache, is there a need to check
L1CFG0?
cfg_FMPLL - The Reference refers to setting the clock with your final
values with RFD+1, then reducing RFD after lock. (1) Why would you
want to set the clock to a series of rates, waiting for locks, such as
the 132MHz example? (2) What is the significance of inhibiting the
cache?
cfg_SRAM - To initialize the SRAM's ECC. Not doing this is probably
bad--more than just loosing ECC, it may flip bits incorrectly on read?
cfg_FLASH - What has changed at this point to allow less internal
flash wait states?
cfg_MMU - If BAM's flat setup of the MMU is adequate, is there any
reason to worry about this?
Thanks in advance.
Steve
[Non-text portions of this message have been removed]