AN2789 - MPC5500 Configuration and Initialization

[stevenaschroeder-2]

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

[Dobbin Allan-r11834]

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]

[Dees Randy-rsaf30]

--- 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
>