ST SPC570S Series Installation and operating instructions

February 2017 DocID030311 Rev 1 1/44
1
AN5010
Application note
SPC570Sx Getting Started
Introduction
The SPC570Sx devices family is built on Power Architecture®technology and is targeted for
ABS and airbag applications that require a high safety integrity level (ISO 26262 for ASIL-D
safety integrity).
In order to minimize additional software and module level features to reach this target, an
on-chip redundancy is offered for the critical components (see Functional Safety chapter of
RM) of the microcontroller by an e200z0Hn2p core, a DMA controller and an interrupt
controller in a delayed lockstep configuration, a crossbar bus system, a memory protection
unit, a fault collection and control unit (FCCU), Flash and SRAM with end-to-end error
correction coding (ECC) and End to end (E2E) protection on the data path and memory
ECC.
This family operates up to 80MHz and offers a high performance processing power specially
if compared with the previous family (SPC56) within a similar power envelope.
Some hardware in the new family also helps to prevent and control critical electronics
system faults and protects against harmful hacks.
This application note details the steps required to properly initialize the SPC570Sx devices
family from power-up to the code execution.
A development flow is described throughout the application note to explain the steps.
It is intended that this application note is read along with the SPC570Sx reference manual,
that can be obtained from the STMicroelectronics website at http://www.st.com (see
Section D.1: Reference documents).
www.st.com

Contents AN5010
2/44 DocID030311 Rev 1
Contents
1 Application example description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Family architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 Differences across sub-family . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Reset and boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 Boot from internal flash . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1 Boot Header format and Boot search locations . . . . . . . . . . . . . . . . . . . 14
3.1.2 HW boot record search (SSCM search) . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3 SW boot record search (BAF search) . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4 SPC570Sx initialization example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Initialization steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 A valid Boot Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Software Watchdog handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 Core registers initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.1 EABI Register initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.2 Core Register initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5 Enable Branch Target Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.6 SRAM ECC Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.7 Environment Initializations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.8 XBAR Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.8.1 XBAR Registers configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.8.2 Flash Memory Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.9 Memory Controllers configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.9.1 Flash Controller configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.9.2 SRAM wait State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.10 Mode Entry Module: Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.11 Clock and PLL configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5 Blink LED application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

DocID030311 Rev 1 3/44
AN5010 Contents
3
Appendix A Copy Initialized Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix B Core registers initialization code . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Appendix C Clocks and PLLs Initialization example. . . . . . . . . . . . . . . . . . . . . . 39
Appendix D Further Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
D.1 Reference documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
D.2 Acronyms and abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

List of tables AN5010
4/44 DocID030311 Rev 1
List of tables
Table 1. Sub-Family features comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Table 2. Flash Memory Map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Table 3. Boot record structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Table 4. Boot record search locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Table 5. Power Architecture EABI Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Table 6. Flash memory port assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Table 7. Acronyms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Table 8. Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

DocID030311 Rev 1 5/44
AN5010 List of figures
5
List of figures
Figure 1. SPC570Sx Block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Figure 2. e200z0h block diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Figure 3. Modules involved in Reset and Boot process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 4. Processor Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 5. Core Execution flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 6. e200z0h SUPERVISOR mode program model SPRs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 7. SRAM ECC Initialization flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 8. Booting flow using GHS startup libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 9. Crossbar switch integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figure 10. 2-way, 4-entry mini-cache organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 11. Mode Entry Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 12. SPC570Sx Clock Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 13. Blink LED application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Application example description AN5010
6/44 DocID030311 Rev 1
1 Application example description
This application note describes the necessary steps to configure the device in order to boot-
up from the Flash and run independent codes out of internal Flash.
This family (SPC57x) superseded the previous one (SPC56x): It is built on 55nm technology
and indeed apart from the technological point of view (55nm versus the older 90nm) it has
been designed to help the user to obtain an ISO26262 ASIL-D compliance for his
applications (see Section D.1: Reference documents).
SPC570Sx by default is configured so to replicate its safety-relevant processing elements
(Core, DMA/DMAMUX, Interrupt Controller) and compares its operation in lockstep (see
Section D.1: Reference documents).
Even if device works in lockstep (LockStep Mode or LSM), from an application perspective
the device behaves as a single core but the user has to take care of its initialization (core
registers, SRAM) to take into account safety architecture peculiarities.
The user can do these initialization by scratch or by using compilers support (through the
compiler property libraries) (see Figure 8: Booting flow using GHS startup libraries) that
allows the user to avoid some core register initializations (see also Section 4.4: Core
registers initialization) as well as the data copy of initialized data from the Flash to SRAM
(see Section 4.7: Environment Initializations) before the user code execution starts.
Note: Even if there are no limitations on the use of whatever compiler/toolchain, in this document
the GHS (Green Hills) syntax has been used where the code has been inserted as an
example.
1.1 Limitations
Since the scope of this document is an introduction on how to start to work with this devices
family, the initialization flow described doesn’t include any safety/security topics as well as it
doesn’t include any special memory handling like memory protection configurations (see
Section D.1: Reference documents).

DocID030311 Rev 1 7/44
AN5010 Family architecture
43
2 Family architecture
Two identical e200z0Hn2p processors (see Figure 1: SPC570Sx Block diagram) are used:
the main core, which executes the software application, and the safety core, linked to the
main core in delayed lock-step mode for ASIL-D safety requirements.
The e200z0h processor family is a CPU core that it implement cost-efficient versions of the
Power Architecture®. 
These processors are designed for deeply embedded control applications which require low
cost solutions rather than maximum performance (see Figure 2: e200z0h block diagram).
CPU is compatible with the Power Architecture VLE (Variable Length Encoding) instruction
set, that allows a mix of 16-bit and 32-bit instructions, for code size footprint reduction.
The processor interface to the external memory space is based on AMBA AHB2.v6
definition, with separate 32-bit data and instruction busses.
These memory busses are connected to the system memories and peripherals through a
32-bit crossbar (XBAR). The two e200z0h processors, the DMA and RAM run up to 80 MHz.
From a software perspective, every bus master (CPU and DMA) sees every memory and
peripheral (SRAM, Flash and peripherals) in a consistent, flat memory address space.
Figure 1.SPC570Sx Block diagram
WŽǁĞƌW
ĞϮϬϬnjϬŚ
yZ
WZ/'ͺϭ
D
&ůĂƐŚZD
EĞdžƵƐϮн
WŽǁĞƌW
ĞϮϬϬnjϬŚ
;ůŽĐŬƐƚĞƉͿ
EĞdžƵƐϮн
:d'D :d' / ^Wh
ĞϮĞ
D
;ůŽĐŬƐƚĞƉͿ
D
DƵdž Zh
D
DƵdž
;ůŽĐŬƐƚĞƉͿ
EĞdžƵƐϯ
WZD W&>^,y/ /EdͺϬ
D,DhyͺϬ
^dhϮ
DͺϬ
tĂŬĞƵƉ
^W/ͺϬ ^W/ͺϭ >ŝŶ&ůĞdžͺϬ
DhͺϬ
dh
&ůĞdžEͺϬ
DDh
dĞŵƉĞƌĂƚƵƌĞ
ƐĞŶƐŽƌ
W/d
ĞdŝŵĞƌͺϬ ĞdŝŵĞƌͺϭ
^ZͺϬ ^Zͺ
^td
DͺZ'D
Dͺ'D
WD/'
DͺD
^DWh
Z
^dD
yZ
^/h> /ZK^ͺ/' yK^ͺ/'W>>ͺ/'ͺϬ
&>^,ͺ/E&
^^D
:d'D
/DW^^^Wh
Zh
y/
ĞϮĞ ĞϮĞ
/Ed /Ed
;ůŽĐŬƐƚĞƉͿ
Zh
Zh
Zh
/ͺϭ
ZD
ĐŽŶƚƌŽůůĞƌ &ůĂƐŚĐŽŶƚƌŽůůĞƌ
WZ/'ͺϬ /ͺϬ
ĞdŝŵĞƌͺϮ
ĞdŝŵĞƌͺϯ
^W/ͺϮ
>ŝŶ&ůĞdžͺϭ
&h
Dhͺϭ
&ůĞdžEͺϭ
DhͺϮ Dhͺϯ
DͺWD
:

Family architecture AN5010
8/44 DocID030311 Rev 1
Figure 2. e200z0h block diagram
CPU
Control Logic
Load/
DataAddress
Store
Unit
Instruction Unit
Branch
Unit
PC
Unit
Instruction Buffer
GPR
CR
SPR
Multiply
Unit
Data Bus Interface Unit
Control
32 32 N
OnCE/Nexus
Control Logic
Interface
Control
Data
(MTSPR/MFSPR)
Integer
Execution
Unit
External
SPR
CTR
XER
LR
Data Address
Instruction Bus Interface Unit
Control
3232N
Nexus
Debug Unit

DocID030311 Rev 1 9/44
AN5010 Family architecture
43
2.1 Differences across sub-family
Table 1. Sub-Family features comparison
SPC570S40x SPC570S50x
Flash 256KB(1)
1. 128KB Block 0 and 128KB Block 1 excluded on SPC570S40x.
512KB
SRAM 32KB(2)
2. [0x4000_8000 - 0x4000_BFFF] out of complete [0x4000_0000 - 0x4000_BFFF] System RAM only
available on SPC570S50.
48KB
FlexCAN 1(3)
3. FlexCAN1 excluded on SPC570S40x.
2
Other aligned to Superset
Table 2. Flash Memory Map
Start Address End address Field RWW partition ID
0x0040_0000 0x0040_1FFF Flash 8 KB UTest block 1
0x0040_2000 0x0040_3FFF Reserved
0x0040_4000 0x0040_5FFF Flash 8 KB BAF block 1
0x0040_6000 0x0040_7FFF Reserved
0x0040_8000 0x0040_BFFF Flash 16 KB Test block(1) 1
0x0040_C000 0x007F_FFFF Reserved
0x0080_0000 0x0080_1FFF Flash 8 KB Data Block 0 2
0x0080_2000 0x0080_3FFF Flash 8 KB Data Block 1 2
0x0080_4000 0x0080_5FFF Flash 8 KB Data Block 2 2
0x0080_6000 0x0080_7FFF Flash 8 KB Data Block 3 2
0x0080_8000 0x00FB_FFFF Reserved
0x00FC_0000 0x00FC_3FFF Flash 16 KB Code Block 0 1
0x00FC_4000 0x00FC_7FFF Flash 16 KB Code Block 1 1

Family architecture AN5010
10/44 DocID030311 Rev 1
0x00FC_8000 0x00FC_BFFF Flash 16 KB Code Block 2 1
0x00FC_C000 0x00FC_FFFF Flash 16 KB Code Block 3 1
0x00FD_0000 0x00FD_7FFF Flash 32KB Code Block 0 1
0x00FD_8000 0x00FD_FFFF Flash 32KB Code Block 1 1
0x00FE_0000 0x00FE_FFFF Flash 64 KB Code Block 0 1
0x00FF_0000 0x00FF_FFFF Flash 64 KB Code Block 1 1
0x0100_0000 0x101_FFFF Flash 128 KB Code Block 0(2) 1
0x0102_0000 0x0103_FFFF Flash 128 KB Code Block 1(3) 1
0x0104_0000 0x3FFF_FFFF Reserved
1. The Test Flash Block is not accessible directly through the Flash controller. It can be accessed only
through a private bus by the SSCM module during the reset and by PASS module when a password match
comparison is requested. The table reports the test Flash Block address, as it were visible from the Flash
controller. In reality, the SSCM and PASS modules access the Test Flash block using the real Flash block
address, which is 0x80_0000 till 0x80_BFFF.
2. Flash Block excluded on SPC570Sx40.
3. Flash Block excluded on SPC570Sx40.
Table 2. Flash Memory Map (continued)
Start Address End address Field RWW partition ID

DocID030311 Rev 1 11/44
AN5010 Reset and boot
43
3 Reset and boot
The power-up reset sequence always begins with the application of the power and follows
different sequences depending on enabled option settings in the DCF records.
This allows the user to control several configuration parameters and customize the final
behavior of the device (see Section D.1: Reference documents).
There are several modules used to step through the sequence needed to properly reset the
SPC570Sx and prepare it to fetch the first instruction of the user application code (see
Figure 3: Modules involved in Reset and Boot process).
These are the Power Management Controller (PMC), the Reset Generation Module (RGM),
the Mode Entry Module (MC_ME), the System Status and Configuration Module (SSCM),
the Self-Test Control Unit (STCU2) and the BAF (Boot Assist Flash) (see Section D.1:
Reference documents for further info on these modules).

Reset and boot AN5010
12/44 DocID030311 Rev 1
Figure 3. Modules involved in Reset and Boot process
Since this document is focused on how to boot-up the device from the internal flash (with no
use of security/safety functions) in the following sections will be detailed how the user has to
configure the device (and its own code) to choose the proper behavior.
3.1 Boot from internal flash
During the reset sequence, the Reset Generation Module (RGM) enables the SSCM which
continues with the reset or boot-up sequence (see Figure 4: Processor Boot). Once the
SSCM locates the boot header, which is stored in Flash (see Table 3: Boot record structure),
it writes the start address information for the core, according to the system configuration, to
special location (CADDR register) in the Mode Entry Module.
As the boot-up sequence progresses, the SSCM instructs the MC_ME to transfer the reset
vector (execution starting address) to the core which starts executing.
ZĞƐĞƚ'ĞŶĞƌĂƚŝŽŶ
DŽĚƵůĞ;Z'DͿ
WŽǁĞƌͲƵƉ
^LJƐƚĞŵ^ƚĂƚƵƐĂŶĚ
ŽŶƚƌŽůDŽĚƵůĞ
;^^DͿ
ŶĂďůĞ^^D^ƚĂƚĞDĂĐŚŝŶĞ
WŽǁĞƌDĂŶĂŐĞŵĞŶƚ
ŽŶƚƌŽůůĞƌ;WDͿ
^ĞůĨdĞƐƚŽŶƚƌŽů
hŶŝƚ;^dhϮͿ
DŽĚĞŶƚƌLJDŽĚƵůĞ
;DͺDͿ
/ĚůĞ
ŽŽƚĐŽƌĞ
ŚŽŝĐĞŚŽǁƚŽ
ƚƵƉƚŚĞĐŽƌĞ
;^^DŽƌ&Ϳ

DocID030311 Rev 1 13/44
AN5010 Reset and boot
43
The system configuration is set as application boot records and is programmed by the
customer. It is used to set the customer application entry point after reset or after the BAF
execution (if enabled).
Figure 4 shows the various possible system boots. The application entry point can be
retrieved both in HW by the SSCM (see Section 3.1.2: HW boot record search (SSCM
search)) or in SW by the BAF (see Section 3.1.3: SW boot record search (BAF search)).
In both cases, the application entry point is retrieved by searching for a valid Boot Record
(see Table 3: Boot record structure), which shall be programmed by the customer in one of
the pre-determined Flash memory locations (see Table 4: Boot record search locations)
looked at by the SSCM or the BAF code.
Figure 4.Processor Boot
>ŝĨĞLJĐůĞ
/Ŷ&ŝĞůĚ
&ŽƵŶĚ
^ĞĂƌĐŚǀĂůŝĚ
ŽŽƚŚĞĂĚĞƌ;ϱŚͿ
z^ EK
ŶĚůĞƐƐůŽŽƉ
KƚŚĞƌƐ &
&ƐĞƌŝĂůƚůŽĂĚĞƌ
&
>ŝĨĞLJĐůĞ
KƚŚĞƌƐ
ĞƐƚƌƵĐƚŝǀĞ
ZĞƐĞƚ
&ŽƵŶĚ
^ĞĂƌĐŚǀĂůŝĚ
ŽŽƚŚĞĂĚĞƌ;ϱŚͿ
EKz^
:ƵŵƉƚŽ
ƉƉůŝĐĂƚŝŽŶĐŽĚĞ
ZĞƐĞƚ >'E
&с&ŝůƵƌĞŶĂůLJƐŝƐ
^^Dс^LJƐƚĞŵ^ƚĂƵƐĂŶĚŽŶĨŝŐƵƌĂƚŝŽŶDŽĚƵůĞ
^^D

Reset and boot AN5010
14/44 DocID030311 Rev 1
3.1.1 Boot Header format and Boot search locations
The boot header (see Table 3: Boot record structure) is used to supply a software entry
point to the core: It is written by the user and loaded into specific locations in the flash
memory (see Table 4: Boot record search locations).
The valid boot record for the SSCM is identified by the 5Ah tag that is different from tag used
for the BAF that is identified by A5h (see Table 3: Boot record structure).
This will make it possible to program the same boot record locations (see Table 4: Boot
record search locations) and launch the application directly after the reset (see
Section 3.1.2: HW boot record search (SSCM search))or after the BAF code execution (see
Section 3.1.3: SW boot record search (BAF search)).
The Boot header is programmed into the flash memory at the same time the user
application program is programmed into flash memory.
Table 4 lists the boot search locations present in the SPC570Sx family. The “Search Order”
column specifies which location is searched first.
Note: The location of the boot record no. 7 is placed within the BAF block itself, making it not
erasable (the BAF block is OTP): This boot record will point to the BAF entry point.

This boot record is the last one being searched by the SSCM (see Section 3.1.2: HW boot
record search (SSCM search)) and this means that, if no other boot record is programmed,
Table 3. Boot record structure
Offset Field description
0x0 Boot Record Tag(1)
1. 5Ah for HW boot record (SSCM), A5h for SW boot record (BAF)
Reserved
0x4 Application start address
0x8 Reserved
0xC Reserved
Table 4. Boot record search locations
Search
order(1)
1. SPC570S40x doesn’t have 128 KB Code Blocks 0 and 1.
Address Location SSCM configuration
parameter
1 0x00FC_0000 Flash 16 KB Code Block 0 RCHW_LO_0
2 0x00FC_4000 Flash 16 KB Code Block 1 RCHW_LO_1
3 0x00FC_8000 Flash 16 KB Code Block 2 RCHW_LO_2
4 0x00FC_C000 Flash 16 KB Code Block 3 RCHW_LO_3
5 0x0100_0000 Flash 128 KB Code Block 0 RCHW_LO_4
6 0x0102_0000 Flash 128 KB Code Block 1 RCHW_LO_5
7 (Last) 0x0040_0000 Flash 8 KB BAF Block RCHW_LO_6

DocID030311 Rev 1 15/44
AN5010 Reset and boot
43
the software will start from the BAF (see Section 3.1.3: SW boot record search (BAF
search)).
3.1.2 HW boot record search (SSCM search)
The SSCM module looks (see Figure 4: Processor Boot) for a valid software entry point
called SSCM boot record (see Table 3: Boot record structure).
The “Application start address“ value will be stored to the CADDR register of MC_ME, which
is used to drive the CPU start address after the reset phase (see Figure 3: Modules involved
in Reset and Boot process).
Depending upon the fact that a valid SSCM boot record is found two actions can happen:
if a valid Boot Record is programmed by the customer, then the application is executed
after the reset from the specified entry point address;
if no valid Boot Record is programmed by the customer, then the default BAF Boot
Record (see Table 4: Boot record search locations) is retrieved and the BAF code is
executed after the reset.
3.1.3 SW boot record search (BAF search)
The BAF is executed if no valid Boot Record (0x005A0000) is programmed by the customer
(see Figure 4: Processor Boot).
Note: In this case a valid SSCM boot record pointing to the BAF code (programmed by factory at
the location number 7) is found (see Table 4: Boot record search locations).
When the BAF code is executed after the reset sequence is completed, a valid application
Boot Record for the application entry point is searched. The mechanism is the same
executed by the SSCM: a set of fixed locations are analyzed (see Table 4: Boot record
search locations) and, if a valid boot record (Boot record tag equal to A5h) is found, then, at
the end of the BAF code, the CPU will start executing from the application entry point.
If no boot header is found in the internal flash memory and the current life cycle phase of the
device is less than ”In Field” (see Figure 4: Processor Boot), an attempt is made to
download the application by a serial protocol using the LINFlexD module or FlexCAN
module (see D.1: Reference documents). The downloaded code is then executed by the
CPU.

SPC570Sx initialization example AN5010
16/44 DocID030311 Rev 1
4 SPC570Sx initialization example
As soon the device ends reset phase, in order to run an application from the Flash memory,
user code has to perform a series of basic initializations (see Section 4.1: Initialization
steps) so to make the device able to run user application taking also into account safety
related initializations (core registers, SRAM, software watchdog) so to avoid safety
reactions as defined by the device’s safety architecture.
Figure 5.Core Execution flow
Note: Dotted blocks added only to indicate temporal dependencies.
&
ŽƌĞƌĞŐŝƐƚĞƌƐŝŶŝƚŝĂůŝnjĂƚŝŽŶ
/ƌĞŐŝƐƚĞƌƐŝŶŝƚŝĂůŝnjĂƚŝŽŶ
^tdŚĂŶĚůŝŶŐ
džĐĞƉƚŝŽŶƐŝŶŝƚŝĂůŝnjĂƚŝŽŶ
ŶĂďůĞƌĂŶĐŚWƌĞĚŝĐƚŝŽŶ
^ZD/ŶŝƚŝĂůŝnjĂƚŝŽŶ
yZŽŶĨŝŐƵƌĂƚŝŽŶ
W&>^,ĂŶĚWZDŽŶĨŝŐƵƌĂƚŝŽŶ
DŽĚĞŽŶĨŝŐƵƌĂƚŝŽŶ
W>>ƐĐŽŶĨŝŐƵƌĂƚŝŽŶĂŶĚůŽĐŬƚƌĞĞ
WŽǁĞƌͲƵƉ
ZĞƐĞƚWŚĂƐĞ
hƐĞƌŽĚĞ

DocID030311 Rev 1 17/44
AN5010 SPC570Sx initialization example
43
4.1 Initialization steps
Below the list of initialization steps the user has to do to run the application from the flash for
a proper execution:
Valid boot header (see Section 4.2: A valid Boot Header) setting
Core registers initialization (see Section 4.4: Core registers initialization)
SWT (Software Watchdog) handling/configuration (see Section 4.3: Software
Watchdog handling)
BTB (Branch Target Buffer) configuration (see Section 4.5: Enable Branch Target
Buffer)
SRAM (ECC) initialization (see Section 4.6: SRAM ECC Initialization)
XBAR configuration (see Section 4.8: XBAR Configuration)
Flash and SRAM controllers configuration (see Section 4.9: Memory Controllers
configuration)
Device Mode configuration (see Section 4.10: Mode Entry Module: Configuration)
PLL and clock tree (selectors/dividers) configuration (see Section 4.11: Clock and PLL
configuration)
Note: The user can do these initialization either in assembly or in C code.
4.2 A valid Boot Header
In order to boot up correctly the device (in the hypothesis of this document) the user has to
provide a valid boot header (see Section 3.1.1: Boot Header format and Boot search
locations).
Below a scratch of code to define (with GHS syntax) a valid boot header for SPC570Sx:
.section .rchw
#ifndef BAF
.LONG 0x005A0000 #/* Valid BH tag if SSCM is choosen */
#else
.LONG 0x00A50000 #/* Valid BH tag if BAF is choosen */
#endif
.LONG _application_start #/* Device Reset Vector (SW entry point)*/
4.3 Software Watchdog handling
The Software Watchdog Timer (SWT) is a peripheral module that can prevent some system
lockup in situations such as the software is getting trapped in a loop or if a bus transaction
fails to terminate.
The SPC570Sx device family has only one SWT. Look at Reference Manual (see D.1:
Reference documents) for more information on configuring and using the SWT.

SPC570Sx initialization example AN5010
18/44 DocID030311 Rev 1
When enabled, the SWT requires periodic execution of a watchdog servicing operation. In
order to prevent a system reset the watchdog must be serviced or disabled prior to the initial
expiry of the timer.
In a real application it is expected that the SWT would be serviced (before the timer expires)
and reconfigured to match the application timing rather than being disabled.
In this document it is supposed the watchdog is disabled to avoid any servicing.
The user has to take care that there is enough time (versus the SWT time period) between
the start of the initialization code (startup code) and the SWT handling function.
In order to disable the watchdog in the software application the user needs to:
Write the sequence of 0xC520 followed by 0xD928 to the service register. This clears
the soft lock bit enabling the next step in the process;
Clear the WEN bit in the Control register;
Below a piece of code(a) that disables the SWT:
;#/*=============================================================*/
;# macro to turn off swt
;# \param[in] swt_baseaddr SWT IP Base address
.macro swt_disable swt_baseaddr
e_li r4, swt_baseaddr@h ;#/* load r4 with SWT base address */
e_or2i r4, swt_baseaddr@l
;#/* Clear soft lock */
e_li r3, 0xC520 ;#/* load r3 with first value */
e_stw r3, 0x10(r4) ;#/* store r3 to SWT Service Register */
e_li r3, 0xD928 ;#/* load r3 with first value */
e_stw r3, 0x10(r4) ;#/* store r3 to SWT Service Register */
e_lis r3, 0xFF00 ;#/* load to r3 SWT Conf . WEN = 0 */
e_or2i r3, 0x010A
e_stw r3, 0(r4) ;#/* store r3 to SWT Control Register */
.endm
Note: When the user is connecting to the device using a debugger, it is likely that the debugger
itself disables the watchdog to allow the debug to be carried out. In the other case if it's not
done this can result in a fairly common problem when attempting to run the code in a
standalone configuration where a periodic device reset is observed, caused by the SWT
time-out.
a. A .macro/.endm block defines the contents of a macro in GHS syntax

DocID030311 Rev 1 19/44
AN5010 SPC570Sx initialization example
43
4.4 Core registers initialization
4.4.1 EABI Register initialization
The Power Architecture Enhanced Application Binary Interface (EABI) specifies certain
general purpose registers as having special meaning for the C code execution.
It defines the system interface for the compiled programs (see Table 5: Power Architecture
EABI Registers).
The symbols _SDA_BASE and _SDA2_BASE are defined during the linking. They specify
the locations of the small data areas. A program must load these values into GPR13 and
GPR2, respectively, before accessing the program data.
The small data areas contain part of the data of the executable. They hold a number of
variables that can be accessed within a 16-bit signed offset of _SDA_BASE or
_SDA2_BASE.
A total of 64k (plus or minus a 32 K offset) bytes may be addressed without changing the
value in the base registers. The 16-bit displacement fits, along with the instruction op-code,
into a single instruction word. This implies a more memory efficient method of accessing a
variable than referencing it by using a full 32-bit address (one instruction to access to it
instead of two).
Typically, the small data areas contain program variables that are less than or equal to 8
bytes in size, although this differs by compiler. The variables in SDA2 are read-only.
Before executing some user codes, the startup code must also set up the stack pointer in
GPR1. This pointer must be 8-byte aligned for the EABI and should point to the lowest
allocated valid stack frame. The stack grows toward lower addresses, so its location should
be selected so that it does not grow into data or bss areas.
Table 5. Power Architecture EABI Registers
Register Content
GPR1 Stack Frame Pointer
GPR2 _SDA2_BASE
GPR13 _SDA_BASE
GPR31 Local variables or environment pointer
GPR0 Volatile - may be modified during linkage
GPR3, GPR4 Volatile - used for parameter passing and return values
GPR5-GPR10 Used for parameter passing
GPR11-GPR12 Volatile - may be modified during linkage
GPR14-GPR30 Used for local variables
FPR0 Volatile register
FPR1 Volatile - used for parameter passing and return values
FPR2-FPR8 Volatile - used for parameter passing
FPR9-FPR13 Volatile registers
FPR14-FPR31 Used for local variables

SPC570Sx initialization example AN5010
20/44 DocID030311 Rev 1
Below an example code to initialize these three pointers:
e_lis r1, __SP_INIT@h ;# Initialize stack pointer r1 to
e_or2i r1, __SP_INIT@l ;# value in linker command file.
e_lis r13, _SDA_BASE_@h ;# Initialize r13 to sdata base
e_or2i r13, _SDA_BASE_@l ;# (provided by linker).
e_lis r2, _SDA2_BASE_@h ;# Initialize r2 to sdata2 base
e_or2i r2, _SDA2_BASE_@l ;# (provided by linker).
Note: This initialization step can be avoided by the user if the compiler has a startup library
support (see Figure 8: Booting flow using GHS startup libraries).
Note: _SDA_BASE_ (_SDA2_BASE_ follows the same strategy) represents the start address of
the sdata section (as defined into the linker file) + 0x8000: the start of the appropriate small
data area section plus 32K.
4.4.2 Core Register initialization
Since in the SPC570Sx family the core is in Lock step, it needs its registers initialization
before any use. In Lock Step mode (LSM), at power on, the two cores will contain different
random data and if for example there is a store to the memory (e.g. stacked) it will cause a
Lock Step error (see Appendix B: Core registers initialization code).