re: MPC5500 Configuration and Initialization

--- In MPC500@..., "stevenaschroeder"
<stevenaschroeder@...> wrote:
>
> 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?
you might want to reserve a large chunk of the cache to be used as
SRAM for fast access (like for the stack to improve interrupt
performance).

You may also may want to lock some code into the cache, also for fast
access.

>(2) If
> you know the particular part has cache, is there a need to check
> L1CFG0?
If you are writing your code to be device independent, you may wasnt
to check for the existence of cache or the size of the cache before
you decide how you want it initialized. Thus you could write code that
wants across multiple devices that have different size caches or even
no cache.

>
> 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?
you may want to control the ramp of current requirements to reduce the
load on your power supply for peak current changes. you can do this by
ramping the speed up.

>
> 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?
the ECC fields of every SRAM location must be initialized before any
of the SRAM can be used for any purpose.

>
> cfg_FLASH - What has changed at this point to allow less internal
> flash wait states?
the device defaults to the maximum wait states (slow access), since
you device does not know the frequency of the crystal itself. Once you
have the PLL configured to your final system frequency, you can set
the wait states for the flash to the optimum performance settings as
defined in the device data sheet for the sytem frequency chosen.

>
> cfg_MMU - If BAM's flat setup of the MMU is adequate, is there any
> reason to worry about this?
Many people want to change the MMU settings to set change the
protection settings for given areas for specific purposes, such as
disable execution from flash areas that are used to store data (and
not instructions)

>
> Thanks in advance.
> Steve
>