ST AN3995 Application note
AN3995
Application note
Getting started tutorial
for SPC564Bxx and SPC56ECxx family
Introduction
The SPC564Bxx and SPC56ECxx is a family of Power Architecture® based microcontrollers
that target automotive vehicle body and gateway applications such as Central body
controller, Smart junction boxes, Front modules, High end gateway, Combined Body
controller and gateway.
These dual core architecture devices contain an e200z4d and e200z0h core, compliant with
the Power Architecture standard.
It provides the scalability needed to implement platform approaches and delivers the
performance required by increasingly sophisticated software architectures.
These devices feature up to 3 MB of internal Flash and up to 256 KB of internal SRAM
memory.
It operates at speeds of up to 120 MHz and offers high performance processing optimized
for low power consumption.
The SPC564Bxx and SPC56ECxx family expands the range of the SPC560B/C
microcontroller family but differs from it by being the first device to feature the e200z4d core
and the e200z0h in a dual core configuration.
The differences between this family and the previous one (SPC560B/C) mean that the
initialization and configuration are different.
This application note details the steps required to properly initialize the SPC564Bxx and
SPC56ECxx from reset as well as how to control the second core. An example code is
described throughout the application note to explain the steps.
It is intended that this application note is read along with the SPC564Bxx and SPC56ECxx
Reference Manual, RM0070 that can be obtained from the STMicroelectronics
http://www.st.com (see Section C.1: Reference document).
®
website at
November 2011 Doc ID 022384 Rev 1 1/49
www.st.com
Contents AN3995
Contents
1 Application example description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Microcontroller boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Boot mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Bootable sectors and RCHW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 e200z4d initialization and example code . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Creating e200z4d Flash boot file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 MMU remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Configure MMU for SRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.3 Initialize the SRAM ECC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.4 Configure MMU for Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.5 Configure MMU for Peripheral Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.6 Memory initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.7 Performance Hints Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 e200z4d device configuration from C code . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Disable watchdog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Mode configuration and clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.3 Clock & PLL configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2.4 Configure Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.5 Starting the e200z0h core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 The e200z4d example code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 e200z0h Initializations and example code . . . . . . . . . . . . . . . . . . . . . . 32
4.1 e200z0h startup code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Appendix A Application code example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.1 main.c file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.2 crt0_corez4_Flash.s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Appendix B Linker file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix C Further information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
C.1 Reference document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2/49 Doc ID 022384 Rev 1
AN3995 Contents
C.2 Acronyms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Doc ID 022384 Rev 1 3/49
List of tables AN3995
List of tables
Table 1. Boot mode selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 2. RCHW field description. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Table 3. Example of MMU configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Table 4. Memory partition schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Table 5. Acronyms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Table 6. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4/49 Doc ID 022384 Rev 1
AN3995 List of figures
List of figures
Figure 1. Boot sector structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Figure 2. SPC564Bxx/SPC56ECxx block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 3. MMU configuration code for SRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 4. SRAM ECC initialization code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 5. MMU configuration code for Flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 6. Code to copy configuration code from Flash to SRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Figure 7. MMU configuration code for peripherals area. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 8. Booting flow using GHS startup libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figure 9. Startup file: __ghs_board_memory_init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 10. Startup file: branch to GHS startup libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 11. Startup file: enable BTB and SPE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 12. Startup file: Flash Configuration code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 13. Startup file: SRAM wait states configuration code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 14. Startup file: XBAR register configuration values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 15. Startup file: XBAR configuration code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 16. Cache Configuration Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 17. Environment configurations code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 18. SWT disabling code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 19. Mode entry diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 20. Mode Initialization Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 21. Peripheral Control Registers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 22. Run peripheral control registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 23. System clock dividers configuration code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 24. PLL configuration code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figure 25. Application code: the main function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Figure 26. e200z0h startup code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Doc ID 022384 Rev 1 5/49
Application example description AN3995
1 Application example description
This application note describes the necessary steps to configure the device in order to run
two independent codes on the two cores.
This family is quite different from the previous one, indeed apart from the memories size
now it has been introduced the dual core concept: in the SPC564Bxx and SPC56ECxx
family the primary core is an e200z4d while the second one is a e200z0h.
While the second core (e200z0h) is thought only as performance core (only to speed up the
execution), the introduction of the e200z4d implies that the user has a more powerful
architecture to cope with the application tasks.
The availability of MMU, ICache and Signal Processing instructions enhance the
performance, but require the correct configuration.
The example code described herein toggles two LEDs with each core running the
application independent of the other.
It has been chosen to treat the two applications separately to better understand the dual
core concept even for compiler projects: of course each project produces one executable
image. The user then has to program the device with both executable images (the
instruction codes are located in different places).
Following this strategy the device is perceived as two separate MCUs each with proprietary
Flash and SRAM.
In this application note, it has been decided to split (in equal parts) the Flash and the SRAM
for both cores.
The memory partition and the XBAR (crossbar architecture) have been optimized for dual
core operations and in particular to give priority to e200z4d core (see Section 3.1.7:
Performance Hints Initialization):
● The SRAM is split over 2 slave ports, 0x4000_0000 to 0x4001_FFFF on slave port 2
(used by e200z4d) and 0x4002_0000 to 0x4003_FFFF on slave port 3 (used by
e200z0h);
● There are 2 Flash ports, z4 instruction port on slave port 0 and a second Flash port for
everything else on slave port 1.
By splitting the SRAM in the linker file(s) so that the e200z4d has access to one block and
the e200z0h has access to the other block, crossbar contentions are generally avoided
between the cores for SRAM access
(a)
(see Appendix B: Linker file).
a. When, for example, there are large amounts of DMA transfers to/from SRAM it could be useful to use the
SRAM allocated to the processor which allows fewer accesses to SRAM. User has to take care that none of
this prevents either core from writing the full SRAM array so care has to be taken in software (using
semaphores and / or software interrupts) to ensure memory coherency.
6/49 Doc ID 022384 Rev 1
AN3995 Microcontroller boot
2 Microcontroller boot
This chapter describes the configuration required by the user, and the steps performed by
the microcontroller
(b)
and in particular, by the SSCM (System Status and Configuration
Module), in order to achieve a successful boot from Flash memory.
For further information, look at SPC564Bxx and SPC56ECxx Reference Manual (see
Section C.1: Reference document).
2.1 Boot mechanism
SPC564Bxx and SPC56ECxx family (as other SPC56xx devices), has two hardware boot
configuration pins, FAB (Force Alternate Boot mode) and ABS (Alternate Boot Select).
These 2 external pins on the microcontroller are latched during reset and used by the SSCM
to determine whether the microcontroller boots from Flash memory or attempts a serial
download via FlexCAN or LINFlex (RS232) (see Tab l e 1 ).
In this application note, the focus is on the default operating mode: the Flash boot mode.
Table 1. Boot mode selection
Mode FAB pin (PA[9]) ABS pin (PA[8])
Flash Boot (Default Mode) 0 –
Serial Boot (LINFlex) 1 0
Serial Boot (FlexCAN) 1 1
When the device is powered on, the SSCM (System Status Configuration Module) searches
the pre-determined locations in Flash for a valid RCHW (Reset Configuration Half Word)
(see Section 2.1.1: Bootable sectors and RCHW).
● If a valid BOOT_ID is found, the SSCM reads the VLE bit and the boot vector address
(as well as the CSE block size).
● If a valid BOOT_ID is not found, the SSCM starts the process of putting the
microcontroller (e200z4d) into static mode
(c)
. See SPC564Bxx and SPC56ECxx family
Reference Manual for detailed information (see Section C.1: Reference document).
Note: The static mode differs from safe mode. Static mode is a non-operational mode which can
only be entered via the BAM (Boot Assist Module).
b. The booting mechanism has an impact only on the e200z4d core.
c. Static Mode Sequence:
1. The SSCM creates a 4 KB MMU page at the start of the BAM with the VLE bit set (the BAM is VLE code).
2. The SSCM then sets the CPU core (e200z4d) instruction pointer to the BAM address and the core starts to
execute the code to enter static mode as follows:
- the Software Watchdog Timer (SWT) is enabled;
- the core executes the "wait" instruction which halts the core.
After the microcontroller enters static mode, the SWT periodically resets the core (approximately every 10 ms)
to re-attempt a boot from Flash memory.
Doc ID 022384 Rev 1 7/49
Microcontroller boot AN3995
In all these conditions, the e200z0h core remains held in reset: for further information please
refer to SPC564Bxx and SPC56ECxx Reference Manual, RM0070 (see Section C.1:
Reference document).
In order to access memory (for the e200z4d core), a valid MMU TLB entry has to be
created. The SSCM does this automatically by reading the reset vector and modifying TLB
entry 0 to create a 4 KB page containing the reset vector address.
The MMU VLE bit is set depending on the status of the VLE bit within the RCHW. The 4 KB
MMU page
(d)
must be 4 KB aligned. This means that the most efficient place to put the
application code is immediately after the boot sector (see Section 2.1.1: Bootable sectors
and RCHW). So in order to maximize the available space inside the 4 KB block, the reset
vector should be set close to the start of a 4 KB boundary.
Note: For example, if the reset vector is set to address 0x0000_0020, then the SSCM aligns the 4
KB MMU page to the start of the 4 KB aligned block containing address 0x0000_0020 – an
MMU page starting at address 0x0000_0000.
Similarly, if the reset vector is set to address 0x0000_0FF0 which is towards the end of an
aligned 4 KB block, the MMU page still has to start at 0x0000_0000 leaving very little room
in the 4 KB MMU page for code execution.
Finally, the SSCM sets the e200z4d core instruction pointer to the reset vector address and
starts the core running.
2.1.1 Bootable sectors and RCHW
In order to successfully boot from Flash memory, the user must program two 32-bit fields
into one of the 5 possible boot blocks (see Figure 1).
The entities to program are:
● 16-bit Reset Configuration Half Word (RCHW), which contains:
– A BOOT_ID field that must be correctly set to 0x5A in order to "validate" the boot
sector;
– A VLE bit which configures the initial MMU entry to either Power Architecture Book
VLE or Power Architecture Book III-E as described later on in this chapter;
● 32-bit reset vector (this is the start address of the user code)
The boot sector also contains a 32-bit field containing the size of the block of data to be
checked by the CSE (Cryptographic Security Engine) during a secure boot. See
SPC564Bxx and SPC56ECxx family Reference Manual, RM0070 for detailed information
(Section C.1: Reference document).
Note: Application code can then be programmed from offset address 0x000C.
d. The 4 KB block provides sufficient space to the user to:
1. Add MMU entries for SRAM and peripherals
2. Perform standard system initialization tasks (initialize the SRAM, setup stack, copy constant data)
3. Transfer execution to RAM, re-define the Flash memory MMU entry and transfer execution back to Flash
memory.
8/49 Doc ID 022384 Rev 1
AN3995 Microcontroller boot
Figure 1. Boot sector structure
0x0000_0000
0x0000_8000
0x0000_C000
0x0001_0000
0x0001_8000
Boot sector 0
32 KB
Boot sector 1
16 KB
Boot sector 2
16 KB
Boot sector 3
32 KB
Boot sector 4
32 KB
Bit 0 Bit 31
0x0
(RCHW)
0x4
0x8
0xC
Code Flash memory
The structure of RCHW is described in Ta bl e 2 :
Table 2. RCHW field description
Boot sector structure
678 1516
Reserved Reserved
32-bit reset vector (points to star t address of application code)
BOOT_ID
(0x5A)
VLE
Size of Flash memory array to be verified by CSE
(see the CSE chapter)
Application code (from offset 0xC and onward)
Field Description
VLE Bit
VLE
0 MMU TLB Entry 0 is configured for Power Architecture Book III-E.
1 MMU TLB Entry 0 is configured for Power Architecture Book VLE.
BOOT_ID
Boot identifier.
If BOOT_ID = 0x5A, the boot sector is considered valid and bootable.
Doc ID 022384 Rev 1 9/49
e200z4d initialization and example code AN3995
3 e200z4d initialization and example code
3.1 Creating e200z4d Flash boot file
In order to run an application from Flash memory, the user code must perform a series of
mandatory actions for proper execution:
● Provide reset vector in the location after the RCHW (Section 2.1: Boot mechanism);
● Configure MMU;
● Initialize SRAM (ECC) (see Section 3.1.3: Initialize the SRAM ECC);
● Configure wait states for Flash and SRAM (see Section 3.1.7: Performance Hints
Initialization);
● Configure XBAR (see Section 3.1.7: Performance Hints Initialization);
● Enable SPE (Signal Processing Extension) instructions if needed by the application
● Enable BTB
Initialization).
3.1.1 MMU remarks
The e200z4d core has a Memory Management Unit (MMU)
the e200z4d core to the XBAR (Crossbar) unless a valid MMU entry is configured for that
access.
(e)
(Branch Prediction Buffers) (see Section 3.1.7: Performance Hints
(f)
which prohibits access from
The user has to take care that the MMU only protects access from the e200z4d core to the
crossbar so that, it does not affect any of the other crossbar masters such as the e200z0h
core, FlexRay or the eDMA (see Figure 2).
e. See section e200z4 core in RM0070 (Section C.1: Reference document)
f. MMU is not present on e200z0h core
10/49 Doc ID 022384 Rev 1
AN3995 e200z4d initialization and example code
Figure 2. SPC564Bxx/SPC56ECxx block diagram
JTAG Port
Nexus Port
NMI0
NMI1
Clocks
Interrupt
Request
Voltage
regulator
16 x
Semaphores
Reset Control
Pad Control
Nexus
FMPLL
SIUL
External
Interrupt
Request
IMUX
GPIO &
RTC/A PI
NMI0
NMI1
4×STM
10 ch
1×12-bit
ADC
JTAGC
Interrupt requests
from peripheral
blocks
CMU
ECSM
SWT
(1)
27 ch or 33 ch
1×10-bit
ADC
Nexus 3+
e200z0h
e200z4d
Nexus 3+
8
PIT RTI
(2)
INTC
×
FlexRay
Instructions
Instructions
MPU
registers
Peripheral Bridge
CTU
FEC
CSE
(Master)
Data
(Master)
(Master)
Data
(Master)
2
32 ch
×
eMIOS
64-bit 8 x 5 crossbar switch
eDMA
(Master)
10
LINFlexD
MPU
×
SRAM
×
128 KB
2
2
×
SRAM
controller
MC_PCUMC_MEMC_CGMMC_RGM
8
DSPI
×
(Slave)
(Slave)
Code Flash
×
1.5 MB
2
Flash memory
controller
DMAMUX
CAN
Sampler
BAM
I2C
Data Flash
64 KB
(Slave)
STCU
SSCM
6
FlexCAN
WKPU
×
Legend:
Notes:
I/O
ADC Analog-to-Digital Converter
BAM Boot Assist Module
CSE Cryptographic Services Engine
CAN Controller Area Network (FlexCAN)
CMU Clock Monitor Unit
CTU Cross Triggering Unit
DMAMUX DMA Channel Multiplexer
DSPI Deserial Serial Peripheral Interface
eDMA enhanced Direct Memory Access
FlexCAN Controller Area Network controller modules
FEC Fast Ethenet Controller
eMIOS Enhanced Modular Input Output System
ECSM Error Correction Status Module
FMPLL Frequency-Modulated Phase-Locked Loop
FlexRay FlexRay Communication Controller
I2C Inter-integrated Circuit Bus
IMUX Internal Multiplexer
INTC Interrupt Controller
(3)
(3)
JTAGC JTAG controller
LINFlexD Local Interconnect Network Flexible with DMA support
MC_ME Mode Entry Module
MC_CGM Clock Generation Module
MC_PCU Power Control Unit
MC_RGM Reset Generation Module
MPU Memory Protection Unit
Nexus Nexus Development Interface
NMI Non-Maskable Interrupt
PIT_RTI Periodic Interrupt Timer with Real-Time Interrupt
RTC/API Real-Time Clock/ Autonomous Periodic Interrupt
SIUL System Integration Unit Lite
SRAM Static Random-Access Memory
SSCM System Status Configuration Module
STM System Timer Module
SWT Software Watchdog Timer
STCU Self Test Control Unit
WKPU Wakeup Unit
1) 10 dedicated channels plus up to 19 shared channels. See the device-comparison table.
2) Package dependent. 27 or 33 dedicated channels plus up to 19 shared channels. See the device-comparison table.
3)
16 x precision channels (ANP) are mapped on input only I/O cells.
Doc ID 022384 Rev 1 11/49
e200z4d initialization and example code AN3995
As previously described in the Section 2.1: Boot mechanism the MMU is not automatically
configured
(g)
apart from a small 4 KB page containing the reset vector address in the TLB
entry 0.
This means that the MMU must be configured by the user, before any access outside to the
block mapped by the SSCM.
In a typical application, the e200z4d core accesses Flash, SRAM and the peripheral blocks
and therefore MMU access needs to be granted.
An example of configuration is showed in Ta bl e 3 .
This configuration is quite similar to the ones implemented in this application note with the
exception of the SRAM 2 memory area (second row of the table). The relative TLB was not
configured because this area is used by the performance core (e200z0h).
Note: The e200z4d core has 16 MMU TLB entries and these allow the user to increase if needed
the protection granularity by splitting the memory in several blocks.
For further information see Memory Protection Unit section in the Reference Manual (see
Section C.1: Reference document).
Table 3. Example of MMU configuration
Memory area Memory address Size Closest MMU size
SRAM 1 0x4000_0000 - 0x4001_FFFF 128KB 128KB
SRAM 2 0x4002_0000 - 0x4003_FFFF 128KB 128KB
Flash including shadow
sector
Peripherals 0xC000_0000 - 0xFFFF_FFFF 1GB 1GB
0x0000_0000 - 0x00FF_FFFF 16MB 16MB
The user has to take into account setting up the stack (see Section 3.1.3: Initialize the
SRAM ECC), prior to performing any RAM accesses like executing the mandatory ECC
initialization, or before any peripheral register writes, the memory spaces have to be
configured through the MMU entries.
These considerations both with small block (4KB) mapped by SSCM on TLB entry 0 by
default (see Section 2.1: Boot mechanism) imply that all MMU regions have to be mapped at
the start of the boot code.
MMU pages must not overlap and must also be configured on a boundary matching their
size (for example, 4 KB MMU page must sit on a 4 KB boundary).
Moreover, it is strongly recommended that the user doesn’t change the MMU configuration
of a memory location currently being accessed, otherwise there is potential for errors.
The suggested order of MMU configuration could be defined as follows:
g. In this device family the Boot Assist Module (BAM) does not run when the device performs a normal Flash boot
then the MMU configurations must be done by the user.
12/49 Doc ID 022384 Rev 1
AN3995 e200z4d initialization and example code
1. Configure the MMU TLB entry for RAM. In this manner, the user code can initialize the
SRAM ECC (see Section 3.1.3: Initialize the SRAM ECC).
2. Configure the MMU TLB entry for Flash
(h)
(see Section 3.1.4: Configure MMU for
Flash)
– Copy configuration code to SRAM
(i)
– Jump to first instruction of this code in SRAM and execute it
– Transfer execution back to the Flash
3. Configure the MMU TLB entry for the IPBridge (peripherals space) (see Section 3.1.5:
Configure MMU for Peripheral Bridge)
3.1.2 Configure MMU for SRAM
In order to configure MMU TLB entries, there are four MMU Assist registers (MAS) which
are written with the TLB entry number, start address and size of the MMU entry and other
information such as whether the page is VLE or BookE instructions.
In Figure 3 is showed a scratch code of MMU configuration
Figure 3. MMU configuration code for SRAM
#/*************************************************************************/
#/* MMU configuration code for SRAM */
#/* TLB1, Entry 1 128KB 0x4000_0000 to 0x4001_FFFF */
#/*************************************************************************/
e_lis r3, 0x1001
mtmas0 r3 #/* MAS0 */
(j)
for RAM using TLB entry 1:
e_lis r3, 0xC000
e_or2i r3, 0x0380
mtmas1 r3 #/* MAS1 = 0xC0000380 (128Kb) */
e_lis r3, 0x4000
e_or2i r3, 0x0028
mtmas2 r3 #/* MAS2 = 0x40000028 */
e_lis r3, 0x4000
e_or2i r3, 0x003F
mtmas3 r3 #/* MAS3 = 0x4000003F */
tlbwe #/* Write the entry to the TLB */
The SRAM space mapped through the TLB 1 is half of the space available on the device
(k)
and it corresponds to the bank placed at the lower addresses.
The example shown here is using this as the upper bank is reserved for the e200z0h core.
h. In this application note the strategy suggested is to re-uses the TLB 0 to map all Flash memory space.
i. User can use this mechanism at this time (the execution from SRAM) to configure the wait states for Flash (see
Section 3.1.7: Performance Hints Initialization): to avoid executing code from Flash while wait states are
changing. This means that should copy also this configuration code to SRAM at this time and execute it with
the MMU ones.
j. After the MAS registers are written, the TLB is validated with a single “tlbwe” (TLB Write Entry) instruction
k. This device family has two 128KB contiguous banks start at 0x4000_0000
Doc ID 022384 Rev 1 13/49
e200z4d initialization and example code AN3995
This means that the e200z4d core doesn’t need to have any mapping on this memory space
(see Section 1: Application example description).
3.1.3 Initialize the SRAM ECC
The SRAM in the SPC564Bxx and SPC56ECxx family (as other SPC56xx devices) has the
ECC (Error Correction Code) protection.
ECC checks are performed during the read portion of an SRAM ECC read/write (R/W)
operation, and ECC calculations are performed during the write portion of a R/W operation.
Because the ECC bits can contain random data after the device is powered on, the SRAM
must be initialized by executing 32-bit write operations prior to any read accesses
ECC error and therefore an exception being raised.
Figure 4 shows a scratch code of SRAM initialization.
Figure 4. SRAM ECC initialization code
#/**************************************************************************/
#/* Initialize all SRAM space by copying all 32GPR's to RAM (fast) */
#/* Counter defines number of 32 x 32-bit words needed to write to RAM*/
#/**************************************************************************/
e_lis r5, _SRAM_ADDR_Z4@h #/* SRAM start address defined in the linker file */
e_or2i r5, _SRAM_ADDR_Z4@l
(l)
to avoid
e_lis r6, _SRAM_SIZE_Z4@h #/* SRAM size defined in the linker file */
e_or2i r6, _SRAM_SIZE_Z4@l
e_srwi r6, r6, 0x7 #/* Divide SRAM size by 128 bytes */
mtctr r6 #/* Move to counter for use with "bdnz" */
sram_loop:
e_stmw r0,0x0(r5) #/* Write all 32 registers to SRAM */
e_addi r5,r5,128 #/* Increment the RAM pointer to next */
e_bdnz sram_loop #/* Loop for all of SRAM */
3.1.4 Configure MMU for Flash
It is strongly recommended (see Section 3.1.1: MMU remarks), not to re-configure an MMU
entry for memory that is currently being used because doing so that can cause stability
issues at the point when the MMU TLB region is re-validated.
From the user point of view this means that it should be fine to configure additional TLB
entries while executing from an existing entry.
Of course users could use the same TLB 0 to map all the Flash but the MMU configuration
code must be executed by the SRAM: the code has to be copied to SRAM and then the
execution flow is transferred to SRAM so that the Flash MMU entry can be safely reconfigured (in this Application Note was described this strategy).
#/* 128byte(4bytes*32 registers) */
Figure 5 shows a scratch code of MMU configuration for Flash using TLB entry 0.
l. This is also true for implicit read accesses caused by any write accesses of less than 32 bits
14/49 Doc ID 022384 Rev 1
AN3995 e200z4d initialization and example code
When the code is executed from Flash, all the code between the labels
“conf_sram_code_begin” and “conf_sram_code_end” is copied
(m)
to and executed from the
SRAM.
Figure 6 shows a scratch code of copy code from Flash to SRAM.
Figure 5. MMU configuration code for Flash
#/**************************************************************************/
#/* MMU configuration code for Flash (TLB1 entry 0) -> copy to RAM */
#/* TLB1 entry 0, 0x0000_0000 to 0x00FF_FFFF overwriting existing TLB */
#/* infact MMU have configured the small 4 KB block at the reset vector. */
#/* NOTE: this configuration allows access to all device Flash */
#/**************************************************************************/
#/* ---- MMU configuration (TLB1, Entry 0) for Code Flash:this block will be
copied to RAM */
e_lis r3, 0x1000 #/* MAS0, Configure TLB1, Entry 0 */
mtmas0 r3
e_lis r3, 0xC000 #/* MAS1 = 0xC0000700 (16MB) */
e_or2i r3, 0x0700
mtmas1 r3
e_lis r3, 0x0000 #/* MAS2 = 0x00000020 */
e_or2i r3, 0x0020
mtmas2 r3
e_lis r3, 0x0000 #/* MAS3 = 0x0000003F */
e_or2i r3, 0x003F
mtmas3 r3
tlbwe #/* Write the entry to the TLB */
Figure 6. Code to copy configuration code from Flash to SRAM
conf_sram:
#/* Calculate number of bytes to copy (data between labels) */
e_lis r3, conf_sram_code_begin@h
e_or2i r3, conf_sram_code_begin@l
e_lis r4, conf_sram_code_end@h
e_or2i r4, conf_sram_code_end@l
subf r4, r3, r4
mtctr r4 #/* Move to counter register the number of bytes to copy */
e_lis r5, _SRAM_ADDR_Z4@h #/* SRAM start address defined in the linker file */
e_or2i r5, _SRAM_ADDR_Z4@l
copy_configuration_code: #/* Copy configuration code from Flash to RAM */
e_lbz r6, 0(r3)
e_stb r6, 0(r5)
e_addi r3, r3, 1
e_addi r5, r5, 1
e_bdnz copy_configuration_code#/* Loop is based on the value of counter */
e_lis r24, _SRAM_ADDR_Z4@h #/* SRAM start address defined in the linker file*/
e_or2i r24, _SRAM_ADDR_Z4@l
se_mtctr r24
se_bctr #/* Jump to the SRAM Start address */
m. As mentioned previously, at this time, user can use this mechanism to configure also the Flash wait states (see
Section 3.1.7: Performance Hints Initialization): he has to put the code between the labels.
Doc ID 022384 Rev 1 15/49
Loading...