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® website at http://www.st.com (see Section C.1: Reference document).

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.1Boot 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 Table 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.1Bootable 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

Boot sector 0

32 KB

Boot sector structure

0x0000_8000

Boot sector 1

16 KB

Bit 0

Bit 31

6 7 8

15 16

0x0000_C000

0x0

BOOT_ID

Boot sector 2

Reserved

VLE

Reserved

16 KB

(RCHW)

(0x5A)

0x4

0x0001_0000

32-bit reset vector (points to start address of application code)

Boot sector 3

32 KB

0x8

Size of Flash memory array to be verified by CSE

(see the CSE chapter)

0xC

Application code (from offset 0xC and onward)

0x0001_8000

Boot sector 4

32 KB

Code Flash memory

The structure of RCHW is described in Table 2:

Table 2.	RCHW field description
	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.1Creating 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(e) (Branch Prediction Buffers) (see Section 3.1.7: Performance Hints Initialization).

3.1.1MMU remarks

The e200z4d core has a Memory Management Unit (MMU)(f) which prohibits access from the e200z4d core to the XBAR (Crossbar) unless a valid MMU entry is configured for that access.

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

			FEC
	JTAGC
JTAG Port			CSE	switch		SRAM	Code Flash	Data Flash
			FlexRay			2 × 128 KB	2 × 1.5 MB	64 KB
Nexus Port		Nexus 3+		crossbar5x8
			Instructions		MPU
Nexus
			Instructions
	NMI0	e200z0h	(Master)			2 × SRAM	Flash memory
			Data
			(Master)			controller	controller
Voltage	NMI1	e200z4d	(Master)	64-bit
regulator
			Data
			(Master)			(Slave)
NMI0		Nexus 3+
								(Slave)
	Interrupt requests						(Slave)
NMI1	from peripheral
	blocks						DMAMUX
			MPU
		INTC
			registers	eDMA
Clocks	CMU						CAN	STCU
				( Master)
FMPLL							Sampler

8×

16 x

RTC/API

4 × STM

SWT

ECSM

PIT RTI

MC_RGM

MC_CGM

MC_ME

MC_PCU

BAM

SSCM

WKPU

Semaphores

Peripheral Bridge

SIUL

10 ch(1)

27 ch or 33 ch(2)

CTU

2 × 32 ch

10 ×

8 ×

I2C

6 ×

Reset Control

1 × 12-bit

1 × 10-bit

LINFlexD

DSPI

FlexCAN

Interrupt

eMIOS

ADC

ADC

Request

External

Interrupt

Request

IMUX

GPIO &

Pad Control

(3)

(3)

I/O

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

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

Notes: 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 Table 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		0x0000_0000 - 0x00FF_FFFF	16MB	16MB
	sector
	Peripherals		0xC000_0000 - 0xFFFF_FFFF	1GB	1GB

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.2Configure 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(j) for RAM using TLB entry 1:

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 */
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.3Initialize 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(l) to avoid 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

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 */
		#/* 128byte(4bytes*32 registers) */
e_bdnz	sram_loop	#/* Loop for all of SRAM */

3.1.4Configure 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).

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

Code to copy configuration code from Flash to SRAM

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.

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