1 - spna106a

Initialization of Hercules ARM Cortex-R4F Microcontrollers (Rev. A)

3 - spna106as

Application Report
SPNA106A – January 2012
Initialization of Hercules™ ARM® Cortex-R4F
Microcontrollers
Sunil Oak........................................................................................................................................
ABSTRACT
This application report provides a brief overview and initialization procedure of the TMS570LS31x series
and the RM4x series of microcontrollers in the Hercules family. "Hercules MCU" will be used henceforth in
this document to refer to any part in these series of microcontrollers.
The document also shows code fragments from source files that are generated using the HALCoGen tool.
All code constructs used in this document are defined in header files also generated by the same utility.
Project collateral and source code discussed in this application report can be downloaded from the
following URL: http://www.ti.com/lit/zip/spna106.
Contents
1
Block Diagram ............................................................................................................... 2
2
Standard Initialization Sequence for Hercules Microcontrollers ...................................................... 3
3
References ................................................................................................................. 15
List of Figures
1
Device Block Diagram ...................................................................................................... 2
2
Color Legend for Block Diagram .......................................................................................... 2
3
FMPLL Block Diagram ..................................................................................................... 6
4
VIM Interrupt Address Memory Map .................................................................................... 14
List of Tables
1
Clock Sources on Hercules Microcontrollers ............................................................................ 7
2
Clock Domains on Hercules Microcontrollers.......................................................................... 10
Hercules is a trademark of Texas Instruments.
Cortex is a trademark of ARM Limited.
ARM is a registered trademark of ARM Limited.
All other trademarks are the property of their respective owners.
SPNA106A – January 2012
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
1
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

Block Diagram
www.ti.com
1
Block Diagram
Section 1 shows a high-level block diagram of the superset TMS570LS31x microcontroller. For the actual
block diagram relevant for any derivative of the TMS570LS series or for the RM4x series of
microcontrollers, see the device-specific data sheet.
3M
64K
256K
ETM-R4
RTP
Flash
64K
RAM
(CPU Trace)
(RAM Trace)
with
64K
with
ECC
ECC
64K
Dual Cortex-R4F
DMA
POM
DMM
HTU1
FTU
HTU2
EMAC
CPUs in Lockstep
Switched Centrol Resource
Switched Centrol Resource
Switched Centrol Resource
Main Cross Bar: Arbitration and :Prioritization Control
64 KB Flash
CRC
Switched Central Resource
Peripheral Central Resource Bridge
for EEPROM
Emulation
with ECC
EMIF
MibADC1
MibADC2
DCAN1
DCAN2
DCAN3
EMAC
Slave
N2HET1
I2C
SCI
LIN
MibSPIx
SPI2
N2HET2
FlexRay
GIO
SPI4
Figure 1. Device Block Diagram
The block diagram includes a color-coded representation of the individual core-power domains
implemented on the microcontroller (see Figure 2). These power domains can be individually turned ON or
OFF during initialization as per the application requirements.
Core/RAM
Core
RAM
always on
#1
#2
#1
#3
#2
#4
#3
#5
Figure 2. Color Legend for Block Diagram
2
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
SPNA106A – January 2012
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

www.ti.com
Standard Initialization Sequence for Hercules Microcontrollers
2
Standard Initialization Sequence for Hercules Microcontrollers
A basic sequence for initialization and configuration of the key features on a Hercules MCU is summarized
below and many steps are detailed in the following sections. The source code example accompanying this
application report demonstrates many of the suggested steps. Some parts of the initialization sequence
are not mandatory. Applications that are non-safety-critical can choose to not use the error correction
coding (ECC) feature for Flash and RAM accesses, for example. Each application must also have its
specific exception handling scheme: reset handler, abort handler, etc. The code generated using
HALCoGen includes template handling routines for each exception. These routines need to be modified as
required by the application.
1. Enable the floating-point unit (FPU) inside the Cortex-R4F CPU (Section 2.1).
2. Initialize the CPU registers and FPU registers, including stack pointers (Section 2.2).
3. Enable the flash interface module's response to an ECC error indicated by the CPU on accesses to
flash (Section 2.3).
4. Enable the CPU's Event Bus export mechanism (Section 2.4).
5. Enable the CPU's Single-Error-Correction Double-Error-Detection (SECDED) logic for accesses to
Flash memory (CPU's ATCM interface) (Section 2.5).
6. Handle the cause of reset to determine whether or not to continue with the start-up sequence
(Section 2.6)
7. Check if any ESM group3 error was indicated during power-up. If any ESM group3 error occurred
during the power-up, it is not safe to continue code execution and the microcontroller initialization
process can be stopped at this point. The subsequent steps in this sequence assume that there was
no ESM group3 error during power-up.
8. Configure PLL control registers with the largest value for the last-stage of the dividers (R-dividers)
(Section 2.7).
9. Enable the Phased-Locked Loops (PLLs) (Section 2.8).
10. Run the eFuse controller start-up checks and start the self-test on the eFuse controller SECDED logic
(Section 2.9).
11. Release the peripherals from reset and enable clocks to all peripherals (Section 2.10).
12. Set up the device-level multiplexing options as well as the input/output (I/O) multiplexing.
13. Wait for the eFuse controller ECC logic self-test to complete and check the results.
14. Set up Flash module for the required wait states and pipelined mode (Section 2.11).
15. Set up Flash bank and pump power modes (Section 2.12).
16. Trim the LPO (Section 2.13).
17. Run the self-test on the SECDED logic embedded inside the Flash module (Section 2.14).
18. Wait for main PLL output to become valid.
19. Map the device clock domains to the desired clock sources (Section 2.15).
20. Reduce the values of the R-dividers in steps to attain the target PLL output frequency for both PLL1
and PLL2.
21. Run a diagnostic check on the CPU self-test controller (Section 2.16). A CPU reset is asserted upon
completion of the CPU self-test. Therefore, the initialization steps leading up to the reset handler will
be repeated.
22. Run the built-in self-test for the CPU (LBIST) (Section 2.17). A CPU reset is asserted upon completion
of the CPU self-test. Therefore, the initialization steps leading up to the reset handler will be repeated.
23. Run a diagnostic check on the CPU compare module (CCM-R4F) (Section 2.18).
24. Run a diagnostic check on the memory self-test controller (Section 2.19).
25. Start a self-test on the CPU RAM using the programmable built-in self-test (PBIST) controller and wait
for this self-test to complete and pass (Section 2.20).
26. Initialize the CPU RAM using the system module hardware initialization mechanism so that the ECC
region for the CPU RAM is also initialized (Section 2.21).
27. Enable the CPU's Single-Error-Correction Double-Error-Detection (SECDED) logic for accesses to
CPU RAM memory (CPU's B0TCM and B1TCM interfaces) (Section 2.22).
SPNA106A – January 2012
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
3
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

Standard Initialization Sequence for Hercules Microcontrollers
www.ti.com
28. Start a self-test on all on-chip dual-port SRAMs using the PBIST controller (Section 2.23).
29. Run the self-test on the CPU's SECDED logic for accesses to main data RAM (B0TCM and B1TCM)
(Section 2.24).
30. Run the self-test on the CPU's SECDED logic for accesses to the main Flash memory (ATCM)
(Section 2.25).
31. Wait for self-test to complete and pass on all on-chip dual-port SRAMs.
32. Start a self-test on all on-chip single-port SRAMs excluding the CPU RAM using the PBIST controller
(Section 2.26).
33. Wait for self-test to complete and pass on all on-chip single-port SRAMs.
34. Start auto-initialization for all other on-chip SRAMs (Section 2.27).
35. Check if the auto-initialization process for all RAMs is completed; wait here if it has not completed.
36. Check the parity error detection mechanism for all peripheral memories (Section 2.28).
37. Enable the CPU’s dedicated vectored interrupt controller (VIC) port (Section 2.29).
38. Program all interrupt service routine addresses in the vectored interrupt manager (VIM) memory
(Section 2.30).
39. Configure IRQ / FIQ interrupt priorities for all interrupt channels (Section 2.30.1).
40. Enable the desired interrupts (IRQ and/or FIQ) inside the CPU (Section 2.31).
41. Enable the desired interrupts in the VIM control registers (Section 2.30.2).
42. Set up the application responses to inputs to the error signaling module (ESM) (Section 2.32).
43. Initialize copy table, global variables, and constructors (Section 2.33).
44. Verify that the dual-clock-comparator (DCC) module can actually detect and flag a frequency error.
45. Configure the DCC module to continuously monitor the PLL output.
46. Verify that a memory protection unit (MPU) violation for all bus masters is flagged as an error to the
ESM.
47. Run a background check on entire Flash using CRC and DMA.
48. Run the offset error calibration routine for the ADC.
49. Run a self-test on the analog-to-digital converter (ADC) analog input channels.
50. Check I/O loop-back for all peripherals.
51. Set up the MPU for the bus masters.
52. Set up the digital windowed watchdog (DWWD) module service window size and the module response
on a violation (reset or NMI).
53. Configure the N2HET1-to-N2HET2 monitoring functionality.
54. Configure desired access permissions for peripherals using the Peripheral Central Resource (PCR)
controller registers.
55. Configure external safety companion, e.g., TI TPS6538x, for online diagnostic operation.
56. Set up the real-time interrupt (RTI) module for generating periodic interrupts as required by the
application.
57. Call the main application (Section 2.35).
4
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
SPNA106A – January 2012
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

www.ti.com
Standard Initialization Sequence for Hercules Microcontrollers
2.1
Enable Floating-Point Coprocessor (FPU)
The floating-point coprocessor is disabled upon a CPU reset and must be enabled if the application
requires floating-point calculations. If a floating-point instruction is executed with the FPU disabled, an
undefined instruction exception is generated.
2.2
Initialize Cortex-R4F Registers
The Hercules series of microcontrollers include dual Cortex-R4F CPUs running in a lock-step operation
mode. A core compare module (CCM-R4) compares the output signals from each R4F CPU. Any
difference in the two CPUs’ outputs is flagged as a fault of a high-severity level. The CPU internal
registers are not guaranteed to power up in the same state for both the CPUs. The CPU pushes the
internal registers on to the stack on a function call, which could lead to the detection of a core compare
error. Therefore, the CPU internal core registers need to be initialized to a predefined state before any
function call is made.
The CPU’s call-return stack consists of a 4-entry circular buffer. When the CPU pre-fetch unit (PFU)
detects a taken procedure call instruction, the PFU pushes the return address onto the call-return stack.
The instructions that the PFU recognizes as procedure calls are, in both the ARM and Thumb instruction
sets:
→ BL immediate
→ BLX immediate
→ BLX Rm
When the return stack detects a taken return instruction, the PFU issues an instruction fetch from the
location at the top of the return stack, and pops the return stack. The instructions that the PFU recognizes
as procedure returns are, in both the ARM and Thumb instruction sets:
→ LDMIA Rn{!}, {..,pc}
→ POP {..,pc}
→ LDMIB Rn{!}, {..,pc}
→ LDMDA Rn{!}, {..,pc}
→ LDMDB Rn{!}, {..,pc}
→ LDR pc, [sp], #4
→ BX Rm
2.3
Enable Response to ECC Errors in Flash Interface Module
The Flash module has a Flash Error Detection and Correction Control Register 1 (FEDACCTRL1) at
address 0xFFF87008. This register controls the ECC functionality implemented inside the Flash module,
including support for the SECDED logic inside the Cortex-R4F CPU. The bits 3–0 of this register make up
the EDACEN field. EDACEN is configured to 0x5 by default. The application must configure EDACEN to
0xA in order to enable the flash module's support for the CPU's SECDED logic.
2.4
Enable the Cortex-R4F CPUs Event Signaling Mechanism
The Cortex-R4F CPU has a dedicated event bus that is used to indicate that an event had occurred. This
event signaling is disabled upon reset and must be enabled. The Flash module and the RAM module
interfaces capture the ECC error events signaled by the CPU. This allows the application to further debug
the exact address, which caused the ECC error.
The CPU event signaling can be enabled by clearing the “X” bit of the performance monitoring unit’s
“Performance monitor control register, c9”.
SPNA106A – January 2012
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
5
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

Standard Initialization Sequence for Hercules Microcontrollers
www.ti.com
2.5
Enable the Cortex-R4F CPUs ECC Checking for ATCM Interface
The CPU has internal ECC logic that protects all CPU accesses to the ATCM (Flash) interface. This logic
is not used by default and must be enabled by setting the ATCMPCEN bit of the System control
coprocessor’s Auxiliary control register, c1.
2.6
Handle the Cause of Reset
Each application has different levels of tolerance for different reset conditions. A typical reset handler is
presented in the accompanying example code project, which identifies all the causes of a reset condition
on the Hercules MCUs.
2.7
Configure PLLs
The Hercules microcontrollers contain a frequency-modulated phase-locked loop (FMPLL) macro that
allows the input oscillator frequency to be multiplied to a higher frequency than can be conveniently
achieved with an external resonator or crystal. Additionally, the FMPLL allows the flexibility to generate
many different frequency options from a fixed crystal or resonator.
The FMPLL allows the application to superimpose a “modulation frequency” signal on the selected base
frequency signal output from the FMPLL. This reduces the electromagnetic energy of the output signal by
spreading it across a controlled frequency range around the base frequency. This mode is disabled by
default, and the application can enable it in applications sensitive to noise emissions.
The Hercules microcontrollers also contain a second non-modulating PLL macro. This PLL#2 can be
independently configured to generate a second high-frequency clock source for specific uses, e.g.,
FlexRay communication clock source of 80 MHz.
2.7.1
FMPLL Block Diagram
Figure 3 shows a high-level block diagram of the FMPLL macro.
OSCIN
/NR
INTCLK
VCOCLK
/OD
post_ODCLK
/R
PLLCLK
PLL
/1 to /64
/1 to /8
/1 to /32
f
= (f
/ NR) * NF / (OD * R)
PLLCLK
OSCIN
/NF
/1 to /256
OSCIN
INTCLK2
VCOCLK2
post_ODCLK2
PLL2CLK
/NR2
/OD2
/R2
PLL#2
/1 to /64
/1 to /8
/1 to /32
f
= (f
/ NR2) * NF2 / (OD2 * R2)
PLL2CLK
OSCIN
/NF2
/1 to /256
Figure 3. FMPLL Block Diagram
The parameters f
, f
and f
are data sheet specifications. To identify the min/max limits on
OSCIN
post_ODCLK
HCLK
these frequencies, see the device-specific data sheet.
NOTE:
The FMPLL takes (127 + 1024*NR) oscillator cycles to acquire lock to the target frequency,
hence it is recommended to configure the FMPLL(s) and enable them as soon as possible in
the device initialization.
6
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
SPNA106A – January 2012
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

www.ti.com
Standard Initialization Sequence for Hercules Microcontrollers
2.7.2
FMPLL Configuration
PLL1 is configured using two control registers, PLL Control 1 Register (PLLCTL1) and PLL Control 2
Register (PLLCTL2), located within the System module on the Hercules microcontrollers.
PLL2 is configured using a single PLL Control 3 Register (PLLCTL3) in the System module.
2.8
Enable Clock Sources
2.8.1
Available Clock Sources on Hercules Microcontrollers
The Hercules microcontrollers support seven different clock sources, as listed in Table 1.
Table 1. Clock Sources on Hercules Microcontrollers
Clock
Source
Number
Clock Source Name
Description
This is the primary oscillator, typically driven by an external resonator or crystal. This
0
OSCIN
is the only available input to the FMPLL and the FMPLL2 macros. The OSCIN
frequency must be between 5 MHz and 20 MHz.
This is the output of the FMPLL, which is generated using the OSCIN as the input
clock. The FMPLL output clock frequency must not exceed the maximum device
1
FMPLL#1 output
frequency specified in the device-specific data sheet. The FMPLL features a
modulation mode where a modulation frequency is superimposed on the FMPLL
output signal.
No clock signal is connected to source #2. This clock source must not be enabled or
2
Not implemented
chosen for any clock domain.
External clock input #1. This clock source must only be enabled if there is an actual
3
EXTCLKIN1
external clock source connected to the identified device terminal for EXTCLKIN1. For
more information, see the device-specific data sheet.
This is the low-frequency output of the internal reference oscillator. The LF LPO is
4
LF LPO
typically an 80 KHz signal, and is generally used for low-power mode use cases.
This is the high-frequency output of the internal reference oscillator. The HF LPO is
5
HF LPO
typically a 10 MHz signal, and is used as a reference clock for monitoring the main
oscillator.
This is the output of the secondary FMPLL, which is generated using the OSCIN as
6
FMPLL#2 output
the input clock. The FMPLL output clock frequency must not exceed the maximum
device frequency specified in the device-specific data sheet.
External clock input #2. This clock source must only be enabled if there is an actual
7
EXTCLKIN2
external clock source connected to the identified device terminal for EXTCLKIN2. For
more information, see the device-specific data sheet.
2.8.2
Control Registers for Enabling and Disabling Clock Sources
There are seven available clock sources on the Hercules microcontrollers:

Clock sources 0, 4 and 5 are enabled, while clock sources 1, 3, 6 and 7 are disabled upon any system
reset.

Clock source 2 is not implemented and must not be enabled in the application.

Each bit of the system module Clock Source Disable Register (CSDIS) controls the clock source of the
same number: bit 0 controls clock source 0, bit 1 controls clock source 1, and so on.

There are also dedicated Clock Source Disable Set (CSDISSET) and Clock Source Disable Clear
(CSDISCLR) registers to allow the application to avoid using read-modify-write operations.

Setting any bit commands, the corresponding clock source to be disabled.
– The clock source can only be disabled once there is no clock domain or secondary clock source
(FMPLL, FMPLL#2) using the clock source to be disabled.
SPNA106A – January 2012
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
7
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

Standard Initialization Sequence for Hercules Microcontrollers
www.ti.com
2.8.3
Example Clock Source Configuration
systemREG1->CSDISCLR = 0x00000000U
| 0x00000001U
// Enable clock source 0
| 0x00000002U
// Enable clock source 1
| 0x00000010U
// Enable clock source 4
| 0x00000020U
// Enable clock source 5
| 0x00000040U;
// Enable clock source 6
The above configuration enables clock sources 0, 1, 4, 5, and 6.
Of the clock sources that are enabled, number 0, 4 and 5 are enabled by default and will have become
valid by the time the processor is released from reset upon a power-up. These are the main oscillator and
the two outputs from the internal reference oscillator.
Clock source 1 and 6 are the two PLL outputs. The FMPLL as well as the FMPLL#2 have a defined
start-up time, and their outputs are not available for use until this time. The application must wait for the
valid status flags for these clock sources to be set before using the PLL outputs for any clock domain. The
example initialization sequence makes use of this PLL lock time to perform all initialization actions that
don'e have to be done at the maximum operating frequency chosen for the application.
2.9
Run Self-Test on the eFuse Controller SECDED Logic
Electrically programmable fuses (eFuses) are used to configure the part after de-assertion of power-on
reset (nPORRST). The eFuse values are read and loaded into internal registers as part of the
power-on-reset sequence. This is called the eFuse autoload. The eFuse values are protected with
single-bit error-correction, double-bit error-detection (SECDED) codes. These fuses are programmed
during the initial factory test of the device. The eFuse controller is designed so that the state of the eFuses
cannot be changed once the device is packaged.
For safety critical systems, it is important for the application to check the status of the eFuse controller
after a device reset. For more details on eFuse controller errors and the application sequence to check for
these errors, see the eFuse Controller chapter of the device-specific technical reference manual.
2.10 Release Reset and Clocks to Peripherals
The peripherals are kept under reset, and need to be explicitly brought out of reset by the application. This
can be done by setting the peripheral enable (PENA) bit of the Clock Control Register (CLKCNTL).
The clocks to the peripheral modules are also disabled upon any system reset and need to be explicitly
enabled by the application. This can be done by setting the bits corresponding to the peripheral select
quadrant occupied by the peripheral module in the Peripheral Central Resource (PCR) Control Registers
for clearing the power down states of peripheral modules (Peripheral Power-Down Clear Register [0:3]
(PSPWRDWNCLRx)). For information on the peripheral select quadrants for each peripheral, see the
device-specific data sheet.
2.11 Configure Flash Access
The Flash memory on the Hercules series microcontrollers is a non-volatile electrically erasable and
programmable memory.
The Hercules microcontrollers contain a digital module that manages all accesses to the Flash memory. A
Flash access can be completed without any wait states required for bus master clock speeds up to 45
MHz. If the bus clock is faster than 45 MHz, then any Flash access requires the appropriate number of
wait states depending on the bus clock speed. The Hercules series microcontrollers support clock speeds
up to 180 MHz. For the actual maximum allowed speed and the number of corresponding address and
data wait states, see the device-specific data sheet.
Suppose that the application requires a CPU clock speed of 180 MHz. This requires 1 address wait state
and 3 data wait states for any access to the Flash memory. These wait states need to be configured in the
Flash module registers.
8
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
SPNA106A – January 2012
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

www.ti.com
Standard Initialization Sequence for Hercules Microcontrollers
The Flash module also features a pipelined mode of operation. When this mode is enabled, the module
reads 128 bits from the Flash memory and holds them in buffers that the CPU can read from without any
wait state. The CPU can read 32 or 64 bits of instructions or data from the pipeline buffers.
The Flash Read Control Register (FRDCNTL) inside the Flash module controls the wait states and the
pipeline mode.
The Hercules MCUs also have a separate Flash bank (bank #7) that is dedicated for data storage. This
bank can be used to emulate an EEPROM. Accesses to this Flash bank are configured via a separate
EEPROM Emulation Configuration Register (EEPROM_CONFIG) in the Flash module. A write operation
to the EEPROM_CONFIG register must first be enabled by configuring the Flash State Machine Write
Enable Control Register (FSM_WR_ENA).
Once the access to the FSM control registers is enabled, the read access to the Flash bank 7 can be
configured.
2.12 Configure Flash Bank and Pump Power Modes
The Flash banks and pump used on the Hercules series microcontrollers support three different operating
modes to optimize power consumption.

Active mode
– Flash bank sense amplifiers and sense reference are enabled
– All circuits of Flash charge pump are enabled

Standby mode (only for Flash banks)
– Flash bank sense reference is enabled but sense amplifiers are disabled

Sleep Mode
– Flash bank sense amplifiers and sense reference are disabled
– All circuits of Flash charge pump are disabled
The Flash banks and charge pump are in the active state by default and after any system reset. The Flash
module allows the application to configure “fall back” power states for the Flash banks and charge pump.
The Flash banks and pump automatically switch the power mode to the selected fall back state when
there is no access to the Flash banks detected within a user-configurable time.
The Flash module also contains special timers to automatically sequence the Flash banks and pump
between the active and the selected fall-back states. A read access to any Flash bank that is in a
non-active power state “wakes up” both the selected bank and the charge pump to active power state.
Programming and erase operations are only allowed on banks in active state.
The Flash Bank Access Control Register (FBAC) controls the Flash banks’ power states.
The Flash Pump Access Control Registers (FPAC1, FPAC2) control the Flash pump's power states.
2.13 Configure Oscillator Monitor
The HF LPO clock source is used as a reference clock for monitoring the main oscillator. A failure is
detected if the oscillator frequency falls outside the range: {f
/ 4, f
*4}.
HFLPO
HFLPO
The HF LPO frequency varies significantly over process corners as well as with changes in the core
supply (VCC) and temperature. The Hercules microcontrollers allow the application to trim the HF LPO
such that the application can choose the operating frequency point of the HF LPO. This in turn determines
the valid range of oscillator frequency.
During device test, a trim value is written into the one-time programmable section of the Flash memory
(OTP), address 0xF008_01B4. Bits 31:16 of this OTP word contain a 16-bit value that may be
programmed into Low Power Oscillator Monitor Control Register (LPOMONCTL) in order to initialize the
trim for HF LPO.
SPNA106A – January 2012
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
9
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

Standard Initialization Sequence for Hercules Microcontrollers
www.ti.com
Alternatively, the application can use the dual-clock compare (DCC) module to determine the trim setting
for the HF LPO. The DCC module allows for comparison of two clock frequencies. Once the HF LPO is
determined to be in-range with the initial HFTRIM setting from the OTP, the crystal oscillator may be used
as a reference against which the HF LPO and LF LPO may be further adjusted. For more details, see the
device-specific technical reference manual.
2.14 Run Self-Test on the Flash Module SECDED Logic
The Flash module reads the “reset configuration vector” from address 0xF0080140 in the TI OTP region of
Flash bank 0. This is a 64-bit value that is used to configure the device power domains, etc. The Flash
module has built-in SECDED logic to correct any single-bit error in this vector or detect and flag and
double-bit error in this vector. If a double-bit error is detected during this read from the OTP, an ESM
group3 error condition is flagged and the nERROR signal is asserted low. If a single-bit error is detected
during the read from the OTP, this error is corrected by the SECDED logic – no flag is set and no error
signal is sent to the ESM.
There are dedicated locations within the TI OTP sector of Flash bank 0 that are programmed to have
single-bit and double-bit errors. Specifically, a 32-bit or 64-bit read from the address 0xF00803F0 results
in a single-bit error indication, and a 32-bit or 64-bit read from the address 0xF00803F8 results in a
double-bit error indication. These locations can be read by the application to ensure that the Flash
interface module is capable of detecting single-bit and double-bit errors upon reads from the OTP.
2.15 Clock Domains
All further initializatio steps are now required to be performed at the max operating frequency for the
application. The application must now wait for the PLLs to lock to their target frequencies, and then map
the device clock domains to the desired clock sources. There are multiple clock domains on the Hercules
microcontrollers to ease the configuration and controllability of the different modules using these clock
domains (see Table 2).
Table 2. Clock Domains on Hercules Microcontrollers
Domain Name
Clock Name
Comments
GCLK controls all the CPU sub-systems, including the floating point
CPU clock domain
GCLK
unit (FPU), and the memory protection unit (MPU)
HCLK shares the same clock source as GCLK, and is always the
System bus clock domain
HCLK
same frequency as HCLK.
VCLK_sys is used for the system modules such as VIM, ESM, SYS,
System peripheral clock domain
VCLK_sys
etc. VCLK_sys is divided down from HCLK by a programmable
divider from 1 to 16.
VCLK is the primary peripheral clock, and is synchronous with
VCLK_sys. VCLK2 is a secondary peripheral clock and is reserved
for use by the enhanced timer module (NHET) and the associated
transfer unit (HTU). VCLK2 is also divided down from HCLK by a
Peripheral clock domains
VCLK, VCLK2, VCLK3
programmable divider from 1 to 16. f
must be an integer multiple
HCLK
of f
, f
must be an integer multiple of f
. VCLK3 is also
VCLK2
VCLK2
VCLK
divided down from HCLK by a programmable divider from 1 to 16,
and is used for the Ethernet and EMIF modules on the TMS570LS3x
microcontrollers.
These clock domains are reserved for use by special communication
modules that have strict jitter constraints. The protocols for these
VCLKA1, VCLKA2, and communication modules (e.g., CAN, FlexRay, Ethernet) do not allow
Asynchronous clock domains
VCLKA4
modulated clocks to be used for the baud rate generation. The
asynchronous clocks allow the clock sources for the baud clocks to
be decoupled from the GCLK, HCLK and VCLKx clock domains.
This clock is used for generating the periodic interrupts by the RTI
Real-time Interrupt clock domains
RTI1CLK
module.
10
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
SPNA106A – January 2012
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

www.ti.com
Standard Initialization Sequence for Hercules Microcontrollers
2.15.1
Mapping Clock Domains to Clock Sources
The system module on the Hercules microcontrollers contains registers that allow the clock domains to be
mapped to any of the available clock sources.
The clock source for the GCLK, HCLK , and VCLKx domains is selected by the GCLK, HCLK, VCLK, and
VCLK2 Source Register (GHVSRC).
The clock sources for the VCLKA1 and VCLKA2 domains are selected via the Peripheral Asynchronous
Clock Source Register (VCLKASRC).
The clock sources for the VCLKA3 and VCLKA4 domains are selected via the Peripheral Asynchronous
Clock Configuration 1 Register (VCLKACON1).
The clock source for the RTI1CLK domain is selected via the RTI Clock Source Register (RCLKSRC).
2.15.2
Example Clock Domain Mapping
systemREG1->GHVSRC
= (0U << 24U)
// Use main oscillator as wake up source for GHV CLK
| (0U << 16U)
// Use main oscillator for HV CLK when GCLK is off
| (1U);
// Use FMPLL as current source for GHV CLK
systemREG1->VCLKASRC = (6U << 8U)
// Use second PLL output for FlexRay bit timing
| (0U);
// Use main oscillator for DCANx bit timings
systemREG1->RCLKSRC
= (1U << 8U)
// Set the RTI1CLK divider to divide-by-2
| (0U);
// Use FMPLL as source for RTI1CLK
2.15.3
Configuring VCLK , VCLK2 and VCLK3 Frequencies
The VCLK and VCLK2 clock signals are divided down from the HCLK clock signal. These are independent
dividers that can be configured via the system module clock control register (CLKCNTL).
NOTE:

VCLK2 frequency must also be an integer multiple of VCLK frequency.

There must be some delay between configuring the divide ratios for VCLK2 and VCLK.
The VCLK3 clock signal is also divided down from the HCLK clock signal. This divider is in the Clock
Control Register 2 (CLK2CNTL).
2.16 Run a Diagnostic Check on CPU Self-Test Controller (STC)
This involves running one CPU self-test interval in STC check mode. The STC self-check mode causes a
stuck-at-0 fault to be introduced inside one of the two CPUs for there to be an STC failure. If no STC
failure is indicated, this would mean that the STC is not capable of detecting a fault inside the CPU, and
device operation is not reliable. For information on the configuration and execution of the STC self-test,
see the device-specific technical reference manual. The CPU will be reset once the STC self-test is
completed. The reset handler routine can resume the device initialization from the next step in the
sequence.
2.17 Run CPU Self-Test (LBIST)
For information on the configuration and execution of the CPU self-test, see the device-specific technical
reference manual. The CPU will be reset once the self-test is completed. The reset handler routine can
resume the device initialization from the next step in the sequence.
SPNA106A – January 2012
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
11
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

Standard Initialization Sequence for Hercules Microcontrollers
www.ti.com
2.18 Run a Diagnostic Check on the CPU Compare Module (CCM-R4F)
The CCM-R4F compares the dual Cortex-R4F CPU outputs on each CPU clock cycle. Any mismatch is
indicated as an ESM group2 error. This ensures that the two CPUs are indeed operating in a lock-step
mode. The CCM-R4F module also allows the application to test the different error conditions using built-in
self-test routines. For information on how to configure the CCM-R4F in a self-test mode, see the
device-specific technical reference manual.
2.19 Run a Diagnostic Check on the Programmable Built-In Self-Test (PBIST) Controller
The PBIST engine is used to run memory test routines on all on-chip memories. It is critical for the
application to rely on this engine being able to detect and report a memory fault condition. Therefore it is
necessary for the application to test this error detection and reporting mechanism before actually using it
to test the on-chip memories. This is done by choosing to run a RAM test routine on a ROM memory. This
test must generate a memory test failure. The application can look for the error flag to ensure that the
PBIST controller can indeed detect and report a memory test failure. For information on how to configure
the PBIST controller for executing specific memory test algorithms on selected on-cip memories, see the
device-specific technical reference manual .
2.20 Start a Self-Test on the CPU RAM Using the PBIST Controller
The CPU RAM is tested first, so that the application can continue to execute while other memories are
being tested later. For information on configuring the PBIST controller, see the device-specific technical
reference manual.
2.21 Initialize the CPU RAM
The system module hardware for auto-initialization of on-chip memories also initializes the associated
ECC or parity locations. This mechanism is now used to initialize the CPU RAM. This process clears the
CPU RAM to all zeros and also programs the corresponding ECC locations.
2.22 Enable the Cortex-R4F CPUs ECC Checking for BxTCM Interface
The CPU has internal ECC logic that protects all CPU accesses to the BTCM (RAM) interfaces. This logic
is not used by default and must be enabled by setting the B1TCMPCEN and B0TCMPCEN bits of the
System control coprocessor’s Auxiliary control register, c1.
2.23 Start a Self-Test on All Dual-Port Memories’ Using the PBIST Controller
Separate algorithms are used for testing single-port versus dual-port on-chip SRAMs. For information on
executing the self-test on the on-chip memories using the programmable BIST (PBIST) engine, see the
device-specific technical reference manual.
2.24 Run a Self-Test on CPU's ECC Logic for Accesses to TCRAM
The CPU TCRAM was initialized earlier, so that all TCRAM is cleared to zeros and the corresponding
correct ECC locations are programmed. The test of the CPU's ECC logic for accesses to TCRAM involves
corrupting the ECC locations to create single-bit and two-bit ECC errors. For the sequence to test the
CPU's ECC logic for accesses to TCRAM, see the device-specific technical reference manual or the
initialization example project. Note that reading from a TCRAM location with a double-bit ECC error
causes the CPU to take a data abort exception. The initialization example project also includes an
example data abort handler.
2.25 Run a Self-Test on CPU's ECC Logic for Accesses to Program Flash
The Flash interface module supports a diagnostic mode (mode 7) that allows the application to test the
CPU's ECC logic for accesses to program Flash. For the sequence to test the CPU's ECC logic for
accesses to program Flash, see the device-specific technical reference manual or the initialization
example project. Note that reading from a program Flash location with a double-bit ECC error causes the
CPU to take a data abort exception. The initialization example project also includes an example data abort
handler.
12
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
SPNA106A – January 2012
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

www.ti.com
Standard Initialization Sequence for Hercules Microcontrollers
2.26 Start a Self-Test on All Single-Port Memories’ Using the PBIST Controller
The CPU RAM can be excluded from this testing as it has already been verified before. For information on
executing the self-test on the on-chip memories using the programmable BIST (PBIST) engine, see the
device-specific technical reference manual.
2.27 On-Chip SRAM Auto-Initialization
The system module on the Hercules microcontroller allows all on-chip SRAMs to be initialized in hardware.
This is especially essential since all the on-chip memories support some form of error detection. The CPU
data RAM supports ECC while the peripheral memories support parity error detection. The
auto-initialization mechanism also initializes the ECC or parity memories, as required.
2.28 Run a Self-Test on All Peripheral RAMsParity Protection Mechanism
Accesses to most peripheral RAMs on this microcontroller are protected by parity error detection. Each of
the peripherals with the parity error detection for its associated memory also includes a self-test mode to
ensure that it is indeed capable of detecting and reporting a parity error on an access to the peripheral
RAM. These self-test mechanisms can be used by the application before enabling use of the concerned
peripheral.
2.29 Enable the Cortex-R4F CPUs Vectored Interrupt Controller (VIC) Port
The CPU has a dedicated port that enables the VIM module to supply the address of an interrupt service
routine along with the interrupt (IRQ) signal. This provides faster entry into the interrupt service routine
versus the CPU having to decode the pending interrupts and identify the highest priority interrupt to be
serviced first.
The VIC port is disabled upon any CPU reset and must be enabled by the application. The VIC is enabled
by setting the VE bit in the CPU’s System Control Register (SYS).
2.30 Vectored Interrupt Manager (VIM) Configuration
The VIM module on the Hercules microcontrollers supports flexible mapping of interrupt request channels
and the interrupt generating sources. The default mapping between the channel number and the
interrupting module is defined in the device-specific data sheet. The interrupt channel number also defines
the inherent priority between the channels, with the lower numbered channel having the higher priority.
That is, the priority decreases in the following order: channel 0 → channel 1 → channel 2 → … channel
95.
For this application report, assume that the application prefers to keep the default priority order between
the channels. For details on the control registers for changing the mapping between interrupt channels
and sources, see the device-specific technical reference manual.
The VIM module contains a memory that holds the starting addresses of the interrupt service routines for
each interrupt enabled in the application. This memory starts at base address 0xFFF82000 on the
Hercules microcontrollers. It is organized in 97 words of 32 bits. The VIM address memory map is shown
in Figure 4.
SPNA106A – January 2012
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
13
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

Standard Initialization Sequence for Hercules Microcontrollers
www.ti.com
Interrupt vector table address space
0xFFF82000
Phantom Vector
0xFFF82004
Channel 0 Vector
0xFFF82008
Channel 1 Vector
0xFFF82178
Channel 93 Vector
0xFFF8217C
Channel 94 Vector
Figure 4. VIM Interrupt Address Memory Map
2.30.1
Configure Interrupts to be Fast Interrupts or Normal Interrupts
Each interrupt request to the VIM can be configured to be forwarded to the CPU as a fast interupt request
(FIQ) or a normal interrupt request (IRQ). The FIQ/IRQ Program Control Registers (FIRQPRx) allow this
selection.
Interrupt requests 0 and 1 are always FIQ. All others are IRQ interrupts by default.
NOTE:
An interrupt request mapped to FIQ cannot use the CPU’s VIC port.
2.30.2
Enabling and Disabling Interrupts
Each interrupt request can be enabled or disabled using the Interrupt Enable Set (REQENASETx) and
Interrupt Enable Clear (REQENACLRx) registers. The interrupt requests 0 and 1 are always enabled and
cannot be disabled. When an interrupt is disabled, it does not prevent the interrupt flag to get set when the
interrupt condition is generated but no IRQ or FIR exception is generated for the Cortex-R4F CPU.
2.31 Enable Interrupts in the Cortex-R4F CPU
Interrupts (IRQ and FIQ) are disabled inside the Cortex-R4F CPU by default and after a CPU reset. The
normal interrupt can be enabled by clearing the "I" bit of the Current Program Status Register (CPSR)
inside the Cortex-R4F CPU, while the fast interrupt (FIQ) can be enabled by clearing the "F" bit of the
CPSR.
2.32 Setup the Error Signaling Module (ESM) Responses to Group1 Errors
The ESM allows the application to choose the module response to errors in the Group1 classification.
These are errors of the lowest severity and can be handled by the application by generating an interrupt to
the CPU. The ESM also offers the capability to indicate any group1 errors on the external nERROR pin.
2.33 Additional Initializations Required by Compiler
If the source program is written using C or C++, the TI compiler requires the creation of the C/C++
run-time environment. This includes:

Initialization of copy table, if required
14
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
SPNA106A – January 2012
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

www.ti.com
References

Initialization of global and static variables defines in C/C++

Initialization of global constructors

Make a function call to branch to the main application
These requirements could be different for each compiler. The compiler reference manual must be referred
to identify the specific requirements for the compiler being used.
2.34 Other Initialization Steps Not Described in this Document
The following is an additional list of operations that an application can perform during the device
initialization.

Verify that the DCC module can detect and report a frequency mismatch error.

Configure the DCC module to continuously monitor the PLL output frequency.

Several bus masters on this microcontroller include their own memory protection units to protect
against accesses to certain parts of the memory map. It is recommended to ensure that violations of
these MPU restrictions are detected and flagged as ESM errors.

Configure the MPU for each bus masters.

Run a background check on the program Flash memory using CRC and DMA.

Calibrate the embedded ADC module for any offset error.

Run a self-test on all ADC inputs to ensure that they are not open or shorted to power or ground.

Run an I/O loop-back check on all peripheral signals.

Configure the windowed watchdog module service window size as well as the module response to a
window violation.

Configure the N2HET1/N2HET2 monitoring capability.

Setup the RTI module to generate periodic interrupts as necessary.

Configure desired access permissions for peripherals using the PCR registers.

Configure any external safety companion chip, e.g., TI TPS6538x, for online diagnostic operation.
2.35 Call the Main Application
This is a normal function call when using C/C++. It could be a branch or branch-link to the name of the
routine that executes the application.
For example:
main();
exit();
3
References

TMS570LSxxx7 16/32-Bit Risc Flash Microcontroller Data Sheet (SPNS162)

TMS570LSxxx5 16/32-Bit Risc Flash Microcontroller Data Sheet (SPNS164)

TMS570LSxxx4 16/32-Bit Risc Flash Microcontroller Data Sheet (SPNS165)

RM48Lx50 16/32-Bit Risc Flash Microcontroller Data Sheet (SPNS174)

RM48Lx40 16/32-Bit Risc Flash Microcontroller Data Sheet (SPNS175)

RM48Lx30 16/32-Bit Risc Flash Microcontroller Data Sheet (SPNS176)

TMS570LS31/21 16/32-Bit RISC Flash Microcontroller Technical Reference Manual (SPNU499)

RM48 16/32-Bit RISC Flash Microcontroller Technical Reference Manual (SPNU503)
SPNA106A – January 2012
Initialization of Hercules™ ARM® Cortex-R4F Microcontrollers
15
Submit Documentation Feedback
Copyright © 2012, Texas Instruments Incorporated

IMPORTANT NOTICE
Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, modifications, enhancements, improvements,
and other changes to its products and services at any time and to discontinue any product or service without notice. Customers should
obtain the latest relevant information before placing orders and should verify that such information is current and complete. All products are
sold subject to TI’s terms and conditions of sale supplied at the time of order acknowledgment.
TI warrants performance of its hardware products to the specifications applicable at the time of sale in accordance with TI’s standard
warranty. Testing and other quality control techniques are used to the extent TI deems necessary to support this warranty. Except where
mandated by government requirements, testing of all parameters of each product is not necessarily performed.
TI assumes no liability for applications assistance or customer product design. Customers are responsible for their products and
applications using TI components. To minimize the risks associated with customer products and applications, customers should provide
adequate design and operating safeguards.
TI does not warrant or represent that any license, either express or implied, is granted under any TI patent right, copyright, mask work right,
or other TI intellectual property right relating to any combination, machine, or process in which TI products or services are used. Information
published by TI regarding third-party products or services does not constitute a license from TI to use such products or services or a
warranty or endorsement thereof. Use of such information may require a license from a third party under the patents or other intellectual
property of the third party, or a license from TI under the patents or other intellectual property of TI.
Reproduction of TI information in TI data books or data sheets is permissible only if reproduction is without alteration and is accompanied
by all associated warranties, conditions, limitations, and notices. Reproduction of this information with alteration is an unfair and deceptive
business practice. TI is not responsible or liable for such altered documentation. Information of third parties may be subject to additional
restrictions.
Resale of TI products or services with statements different from or beyond the parameters stated by TI for that product or service voids all
express and any implied warranties for the associated TI product or service and is an unfair and deceptive business practice. TI is not
responsible or liable for any such statements.
TI products are not authorized for use in safety-critical applications (such as life support) where a failure of the TI product would reasonably
be expected to cause severe personal injury or death, unless officers of the parties have executed an agreement specifically governing
such use. Buyers represent that they have all necessary expertise in the safety and regulatory ramifications of their applications, and
acknowledge and agree that they are solely responsible for all legal, regulatory and safety-related requirements concerning their products
and any use of TI products in such safety-critical applications, notwithstanding any applications-related information or support that may be
provided by TI. Further, Buyers must fully indemnify TI and its representatives against any damages arising out of the use of TI products in
such safety-critical applications.
TI products are neither designed nor intended for use in military/aerospace applications or environments unless the TI products are
specifically designated by TI as military-grade or "enhanced plastic." Only products designated by TI as military-grade meet military
specifications. Buyers acknowledge and agree that any such use of TI products which TI has not designated as military-grade is solely at
the Buyer's risk, and that they are solely responsible for compliance with all legal and regulatory requirements in connection with such use.
TI products are neither designed nor intended for use in automotive applications or environments unless the specific TI products are
designated by TI as compliant with ISO/TS 16949 requirements. Buyers acknowledge and agree that, if they use any non-designated
products in automotive applications, TI will not be responsible for any failure to meet such requirements.
Following are URLs where you can obtain information on other Texas Instruments products and application solutions:
Products
Applications
Audio
www.ti.com/audio
Automotive and Transportation www.ti.com/automotive
Amplifiers
amplifier.ti.com
Communications and Telecom
www.ti.com/communications
Data Converters
dataconverter.ti.com
Computers and Peripherals
www.ti.com/computers
DLP® Products
www.dlp.com
Consumer Electronics
www.ti.com/consumer-apps
DSP
dsp.ti.com
Energy and Lighting
www.ti.com/energy
Clocks and Timers
www.ti.com/clocks
Industrial
www.ti.com/industrial
Interface
interface.ti.com
Medical
www.ti.com/medical
Logic
logic.ti.com
Security
www.ti.com/security
Power Mgmt
power.ti.com
Space, Avionics and Defense
www.ti.com/space-avionics-defense
Microcontrollers
microcontroller.ti.com
Video and Imaging
www.ti.com/video
RFID
www.ti-rfid.com
OMAP Mobile Processors
www.ti.com/omap
Wireless Connectivity
www.ti.com/wirelessconnectivity
TI E2E Community Home Page
e2e.ti.com
Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265
Copyright © 2012, Texas Instruments Incorporated

Document Outline


4 - TMS570_Startup_BootStartup_MDD

Module --

High-Level Description

This module outlines the functionality of the system startup functions of the TMS570. This code is intended to be run starting after the sys startup routine in the boot project.

Figures

Diagram – Function Data Sharing

This diagram shows all data that is shared between functions within the module.

No Shared Data


Variable Data Dictionary

For details on module input / output variable, refer to the Data Dictionary for the application. Input / output variable names are listed here for reference.

Module InputsModule Outputs

Module Internal Variables

This section identifies the name, range and resolutions for module specific data created by this module. If there are no range restrictions on the variable, the term “FULL” is placed into the table for legal range.

Variable NameResolution

Legal Range

(min)

Legal Range

(max)

Software Segment
<None>

User defined typedef definition/declaration

This section documents any user types uniquely used for the module.

Typedef NameElement NameValue

Constant Data Dictionary

Calibration Constants

This section lists the calibrations used by the module. For details on calibration constants, refer to the Data Dictionary for the application.

Constant Name
<None>

Program(fixed) Constants

Embedded Constants

All embedded constants whose values are provided in Eng units will be evaluated to the equivalent counts by using the FPM_InitFixedPoint_m() macro within the #define statement.

Local

Constant NameResolutionUnitsValue

Global

This section lists the global constants used by the module. For details on global constants, refer to the Data Dictionary for the application.

Constant Name

Module specific Lookup Tables Constants

(This is for lookup tables (arrays) with fixed values, same name as other tables)

Constant NameResolutionValueSoftware Segment
None


Functions/Macros used by the Sub-Modules

Library Functions / Macros

The library and functions / Macros that are called by the various sub modules are identified below,

  1. <None>

Data Hiding Functions

  1. <None>

Global Functions/Macros Defined by this Module

Global Function #1

Function Name(Exact name used)TypeMinMaxUTP Tol.
Arguments Passed(if none, write None)
(Insert more rows for additional passed arguments)
Return Value(if no value returned, write N/A)

Description

(Place flowchart/design for local function)

Local Functions/Macros Used by this MDD only

Local Function #1

Function Name(Exact name used)TypeMinMaxUTP Tol.
Arguments Passed(if none, write None)
(Insert more rows for additional passed arguments)
Return Value(if no value returned, write N/A)

Description

(Place flowchart/design for local function)

Software Module Implementation

Runtime Environment (RTE) Initial Values

This section lists the initial values of data written by this module but controlled by the RTE. After RTE initialization, the data in this table will contain these values.

DataValue
<None>

Initialization Functions

(Note: For multiple init functions, insert new headers at the “Header 2” level – subset of “5.1 Initialization Functions” and follow the same sub-section design shown below)

Init: BootStartup

Design Rationale

This function is designed to be called at the end of the sys_startup initialization routine. Note that most of this initialization code (for initializing copy table, global variables, and constructors) was taken from Texas Instruments’ startup code example implementation.

Processing


Periodic Functions

None

Fault Recovery Functions

None

Shutdown Functions

None

Interrupt Functions

None

Serial Communication Functions

None


Execution Requirements

Execution Sequence of the Module

Execution Rates for sub-modules called by the Scheduler

This table serves as reference for the Scheduler design

Function NameCalling FrequencySystem State(s) in which the function is called
BootStartup()called by sys_startup initialization codeN/A

Execution Requirements for Serial Communication Functions

Function NameSub-Module called by (Serial Comm Function Name)
<None>


Memory Map Definition Requirements

Sub Modules (Functions)

This table identifies the software segments for functions identified in this module.

Name of Sub ModuleSoftware Segment
BootStartup()

Local Functions

This table identifies the software segments for local functions identified in this module.

Name of Sub ModuleSoftware Segment


Known Issues / Limitations With Design

  1. (Item #1)


Revision Control Log

Item #Rev #Change DescriptionDateAuthor Initials
11Initial creation05/14/12LWW

5 - TMS570_Startup_FiqIntVect_MDD

High-Level Description

fiqintvect provides the assembly language fiq handling function. The function loads the program counter with the value of the FIQ Interrupt Vector Register, which contains the address of the ISR with the highest priority pending FIQ request.

Figures

Diagram – Function Data Sharing

No Shared Data

Variable Data Dictionary

For details on module input / output variable, refer to the Data Dictionary for the application. Input / output variable names are listed here for reference.

(Note: Full variable names required in table.)

(Note: All global variables including End Of Line data used should be shown here)

Module InputsModule Outputs
<None><None>

Module Internal Variables

This section identifies the name, range and resolutions for module specific data created by this module. If there are no range restrictions on the variable, the term “FULL” is placed into the table for legal range.

Variable NameResolution

Legal Range

(min)

Legal Range

(max)

Software Segment
<None>

User defined typedef definition/declaration

This section documents any user types uniquely used for the module.

Typedef NameElement NameUser Defined Type

Legal Range

(min)

Legal Range

(max)

<None>

Constant Data Dictionary

Calibration Constants

This section lists the calibrations used by the module. For details on calibration constants, refer to the Data Dictionary for the application.

Constant Name
<None>

Program(fixed) Constants

Embedded Constants

All embedded constants whose values are provided in Eng units will be evaluated to the equivalent counts by using the FPM_InitFixedPoint_m() macro within the #define statement.

Local

Constant NameResolutionUnitsValue
<None>

Global

This section lists the global constants used by the module. For details on global constants, refer to the Data Dictionary for the application.

Constant Name
<None>

Module specific Lookup Tables Constants

(This is for lookup tables (arrays) with fixed values, same name as other tables)

Constant NameResolutionValueSoftware Segment
<None>


Functions/Macros used by the Sub-Modules

Library Functions / Macros

The library and functions / Macros that are called by the various sub modules are identified below,

  1. <None>

Data Hiding Functions

  1. <None>

Global Functions/Macros Defined by this Module

NOTE that all global functions in this module must be assembled in ARM mode. Therefore the .asm source file includes the .arm directive at the beginning of the file, applying the directive to all functions in the file.

Global Function #1

Function Name_fiqhandlerTypeDir.MinMaxUTP Tol.
Arguments PassedNone
Return ValueNone

Design Rationale

This function is required when more than one FIQ is configured in the system. When only one FIQ is configured, its ISR can be directly configured in DaVinci as the FIQ Handler. (Alternatively, the _fiqhandler function could be configured and its code changed to branch to the one FIQ ISR.) When there are multiple FIQs, the _fiqhandler function is needed so that the one handler configured in DaVinci will go to the correct ISR address as found in the processor FIQ Interrupt Vector Register.

Description

Loads the program counter with the value of the FIQ Interrupt Vector Register, which contains the address of the ISR with the highest priority pending FIQ request.

.def _fiqhandler

.asmfunc

_fiqhandler

ldr r8, fiqvectreg

ldr pc, [r8]

fiqvectreg .word 0xFFFFFE74

.endasmfunc

Local Functions/Macros Used by this MDD only

None

Software Module Implementation

Runtime Environment (RTE) Initial Values

This section lists the initial values of data written by this module but controlled by the RTE. After RTE initialization, the data in this table will contain these values.

DataValue
<None>

Initialization Functions

None

Periodic Functions

None

Fault Recovery Functions

None

Shutdown Functions

None

Interrupt Functions

None

Serial Communication Functions

None

Execution Requirements

Execution Sequence of the Module

(Describe in words relevant details about the execution sequence of the different sub modules.)

Execution Rates for sub-modules called by the Scheduler

This table serves as reference for the Scheduler design

Function NameCalling FrequencySystem State(s) in which the function is called
<None>

Execution Requirements for Serial Communication Functions

Function NameSub-Module called by (Serial Comm Function Name)
<None>

Memory Map Definition Requirements

Sub Modules (Functions)

This table identifies the software segments for functions identified in this module.

Name of Sub ModuleSoftware Segment
_fiqhandlerN/A

Local Functions

This table identifies the software segments for local functions identified in this module.

Name of Local FunctionSoftware Segment
None

Known Issues / Limitations With Design

None

Revision Control Log

Item #Rev #Change DescriptionDateAuthor Initials
11.0Initial Revision of MDD6/10/2013KMC

6 - TMS570_Startup_Integration_Manual

1 Dependencies 2

1.1 SWCs 2

1.2 Functions to be provided to Integration Project 2

1.3 Functions to be provided by Integration Project 2

2 Configuration 2

2.1 Build Time Config 2

2.2 Configuration Files to be provided by Integration Project 2

2.2.1 startup_cfg.h 3

2.2.2 appinit_cfg.h 3

2.3 DaVinci Config Configuration Changes 3

2.4 Manual Configuration Changes 3

3 Integration 3

3.1 Required Global Data Inputs 3

3.2 Optional Global Data Inputs 3

3.3 Specific Include Path present 3

3.4 Build Exclusions 3

3.5 Definition of Stacks 4

3.6 Reset Causes 4

3.7 Impact on Integration Project 6

3.7.1 JTAG Debugger Considerations 6

3.7.2 RAM Memory State 7

3.7.3 ECC and Parity 7

4 Runnable Scheduling 7

5 Memory Mapping 7

5.1 .resetcause Section 7

5.2 Mapping 7

5.3 Usage 7

5.4 NvM Blocks 8

6 Compiler Settings 8

6.1 Preprocessor MACRO 8

6.2 Optimization Settings 8

6.3 Other Settings 8

7 Revision Control Log 8

Dependencies

SWCs

ModuleRequired Feature
StdDefTMS570 Register Definitions

Functions to be provided to Integration Project

void _fiqhandler(void);

uint32 _coreGetDebugStatusAndControlRegister_(void);

uint32 _coreGetSecondaryAuxiliaryControlRegister_(void);

void _coreSetSecondaryAuxiliaryControlRegister_(uint32 SecAuxCtrlRegVal_Cnt_T_u32);

uint32 _coreGetFPSCR_(void);

Functions to be provided by Integration Project

All common functionality required for a boot project startup is contained in “BootStartup.c”, and all common functionality for application project startup is contained in “AppStartup.c”. There may be instances, however, where a boot or application project will need to do special steps that are specific to a particular program, prior to the “main()” function call. To accommodate this, several functions are called, one at the start and one at the end of both BootStartup.c and AppStartup.c. These functions are

  • void BootStartupCallout1(void)

  • void BootStartupCallout2(void)

  • void AppStartupCallout1(void)

  • void AppStartupCallout2(void)

The integration projects are required to provide these functions, regardless of if there is content in them.

Configuration

Build Time Config

ModulesNotesSWC
None

Configuration Files to be provided by Integration Project

Configuration files are needed to configure the startup sequence based on the needs of the program being implemented in. These configuration files are simply header files that define a set of build constants. Templates of these files are provided (located in the tools folder of this SWC) that can be adapted to the needs of the program. From the context of a boot project, startup_cfg.h is required. From the context of an application project, appinit_cfg.h is required.

startup_cfg.h

This file contains the startup configuration constants used in sys_startup. The following constants can be enabled or disabled defining them as either STD_OFF or STD_O, descriptions are as follows:

appinit_cfg.h

DaVinci Config Configuration Changes

ParameterValueNotes
OsOSFIQHandler_fiqhandlerNeeds to be configured if more than one FIQ is configured in the system (e.g. when adding the floating point exception handling FIQ). When only one FIQ is configured, the value of this parameter should be the name of that one FIQ ISR.

Manual Configuration Changes

ConstantNotesSWC
None

Integration

Required Global Data Inputs

None

Optional Global Data Inputs

None

Specific Include Path present

Yes

Build Exclusions

This component is designed to be included in a given program’s boot and application projects. The boot project is defined as the project which the hardware reset vector jumps to. A subset of this component’s files needs to be part of the build based on given context. The source files to be excluded from the build through code composer project settings are as follows:

Excluded from Boot Project:

  • AppStartup.c

Excluded from the Application Project:

  • BootStartup.c

  • sys_startup.c

Definition of Stacks

The stacks (sizes and locations) need to be defined and reserved by both the boot and application integration projects. This can be done by defining symbols for the locations of the stack (typically in the linker file). The stack symbols (used to initialize the stack pointers) the startup code requires are:

  • “_StackSVC_”

  • “_StackFIQ_”

  • “_StackIRQ_”

  • “_StackUSER_”

  • “_StackABORT_”

  • “_StackUND_”

Reset Causes

A variable of this SWC holds the reset cause and it is used to alter the processing of the startup sequence. This SWC defines a set of reset causes shown in the table below. The integration project is free to define its own reset cause values if necessary and write this value to the ResetCause_Cnt_Enum variable prior to performing a software reset; however, the names and values in the table below are reserved for use of this SWC. The ResetCause_Cnt_Enum variable can be read at any time by integration project components for information or diagnostic use.

Reset Cause NameValue
PWRONRESET0x0000FFFF
DEBUGRESET0x0001FFFE
CPURESET0x0002FFFD
SPPBISTFAILED0x0003FFFC
DPPBISTFAILED0x0004FFFB
EXTRESET0x0005FFFA
OSCFAIL0x0006FFF9
SWRESET0x0007FFF8
WDGFAIL0x0008FFF7
CCMSTEFFAILED0x0009FFF6
CCMSTFAILED0x000AFFF5
CCMEFFAILED0x000BFFF4
PBISTSCFAILED0x000CFFF3
STCSCFAILED0x000DFFF2
STCFAILED0x000EFFF1
ESM3NONZERO0x000FFFF0
EFCSTFAILED0x0010FFEF
EFCSTUCKZERO0x0011FFEE
EFCERROR0x0012FFED
FLSBUS2CORRFAILED0x0013FFEC
FLSBUS2ADDCAPFAILED0x0014FFEB
FLSBUS2MULBITDETFAILED0x0015FFEA
FLSBUS2SNGBITDETFAILED0x0016FFE9
VIMPARFLGFAILED0x0017FFE8
VIMPARADDERRFAILED0x0018FFE7
VIMPARESMFAILED0x0019FFE6
DCAN1PARESMFAILED0x001AFFE5
DCAN2PARESMFAILED0x001BFFE4
DCAN3PARESMFAILED0x001CFFE3
DMAPARESMFAILED0x001DFFE2
MIBADC1PARESMFAILED0x001EFFE1
MIBADC2PARESMFAILED0x001FFFE0
MIBSPI1PARESMFAILED0x0020FFDF
MIBSPI3PARESMFAILED0x0021FFDE
MIBSPI5PARESMFAILED0x0022FFDD
N2HET1PARESMFAILED0x0023FFDC
N2HET1TUPARESMFAILED0x0024FFDB
N2HET2PARESMFAILED0x0025FFDA
N2HET2TUPARESMFAILED0x0026FFD9
B0MULBITRAMECCDETFAILED0x0027FFD8
B1MULBITRAMECCDETFAILED0x0028FFD7
B0SNGBITRAMECCDETFAILED0x0029FFD6
B1SNGBITRAMECCDETFAILED0x002AFFD5
SNGBITFLSECCDETFAILED0x002BFFD4
MULBITFLSECCDETFAILED0x002CFFD3
LPOTRIMERROR0x002DFFD2
DATAMULBITRAMECCFAILED0x002EFFD1
DATAMULBITFLSECCFAILED0x002FFFD0
CPUDATAABORT0x0030FFCF
CPUPREFETCHABORT0x0031FFCE
PRFTCMULBITRAMECCFAILED0x0032FFCD
PRFTCMULBITFLSECCFAILED0x0033FFCC
UNDEFINST0x0034FFCB
CLOCKMONITOR0x0035FFCA
CCMFAILED0x0036FFC9
FMCUNCORRERR0x0037FFC8
B0UNCORRERR0x0038FFC7
B1UNCORRERR0x0039FFC6
B0ADDPARERR0x003AFFC5
B1ADDPARERR0x003BFFC4
FLSECCLIVELOCK0x003CFFC3
VIMMULTBITFLT0x003DFFC2
VIMPARTHRSHFLT0x003EFFC1
UNUSEDINTERRUPT0x003FFFC0
STACKOVERWRITE0x0040FFBF
MPUVIOLATION0x0041FFBE
WDGALIVEMONFAIL0x0042FFBD
WDGDEADLINEFAIL0x0043FFBC
WDGPROGFLOWFAIL0x0044FFBB
SWWDGFAIL0x0045FFBA
FPUDZCEXCP0x0046FFB9
FPUOFCEXCP0x0047FFB8
FPUIOCEXCP0x0048FFB7
FPUUNKNOWNEXCP0x0049FFB6

Impact on Integration Project

JTAG Debugger Considerations

Integrating this project will impact the debugging capabilities. The normal startup which runs all of the diagnostic startup tests will be bypassed if a debugger connection is detected. Because of safety ramifications of potentially bypassing startup tests if the controller incorrectly reads a debugger being attached, a branch to self instruction is inserted in AppStartup.c if the reset cause is “DEBUGRESET”. In the scenario where a debugger is actually attached, the user running the debug session will have to manually move the program-counter past this branch instruction to continue debugging.

RAM Memory State

This SWC will leave the RAM cleared to all zeros only on a Power-On Reset. All other resets will bypass any RAM manipulation. It is the responsibility of the boot project and application project to make certain the initial state of RAM is proper for all reset scenarios.

ECC and Parity

The sys_startup function will exit in a state with both RAM and Flash ECC turned on. If this is not the desired state for either the boot or application code, the callout functions could potentially be used to change this (e.g. the boot callout could turn off flash ECC, and the application callout could turn flash ECC back on).

The AppStartup can be configured to test parity on the applicable peripheral RAM. After the test, the parity will be left in the enabled state; however, the integration application code will need to configure response to failures (ISRs, etc).

Runnable Scheduling

This section specifies the required runnable scheduling.

InitScheduling RequirementsTrigger
RunnableScheduling RequirementsTrigger

Memory Mapping

.resetcause Section

A “.resetcause” memory section must be defined in both the boot and application linker file. This holds a 32bit variable to be located in RAM memory. This variable is shared between the boot and the application projects, and therefore must be located in a shared, fixed memory location.

Mapping

Memory SectionContentsNotes

* Each …START_SEC… constant is terminated by a …STOP_SEC… constant as specified in the AUTOSAR Memory Mapping requirements.

Usage

Table 1: ARM Cortex R4 Memory Usage

FeatureRAMROM
Full driver

NvM Blocks

Block Name

Compiler Settings

Preprocessor MACRO

<Define all the preprocessor Macros needed and conditions when needed>.

Optimization Settings

<Define Optimization levels that are needed and conditions when needed>.

Other Settings

Revision Control Log

Rev #Change DescriptionDateAuthor Initials
1Initial versionLWW
2Updated to latest Integration Manual Template; Updated reset cause table (section 3.5); Removed sys_core.asm and sys_memory.asm from list of modules needing special compilation (section 6.3) (handled by a directive in the asm files); added information on configuring _fiqhandler6/10/2013KMC
3Removed requirement of compilation of sys_startup and AppStartup in arm mode08/02/13LWW

7 - TMS570_Startup_SysCore_MDD

High-Level Description

sys_core provides assembly language functions for processor register data access and system startup.

Figures

Diagram – Function Data Sharing

No Shared Data

Variable Data Dictionary

For details on module input / output variable, refer to the Data Dictionary for the application. Input / output variable names are listed here for reference.

(Note: Full variable names required in table.)

(Note: All global variables including End Of Line data used should be shown here)

Module InputsModule Outputs
<None><None>

Module Internal Variables

This section identifies the name, range and resolutions for module specific data created by this module. If there are no range restrictions on the variable, the term “FULL” is placed into the table for legal range.

Variable NameResolution

Legal Range

(min)

Legal Range

(max)

Software Segment
<None>

User defined typedef definition/declaration

This section documents any user types uniquely used for the module.

Typedef NameElement NameUser Defined Type

Legal Range

(min)

Legal Range

(max)

<None>

Constant Data Dictionary

Calibration Constants

This section lists the calibrations used by the module. For details on calibration constants, refer to the Data Dictionary for the application.

Constant Name
<None>

Program(fixed) Constants

Embedded Constants

All embedded constants whose values are provided in Eng units will be evaluated to the equivalent counts by using the FPM_InitFixedPoint_m() macro within the #define statement.

Local

Constant NameResolutionUnitsValue
<None>

Global

This section lists the global constants used by the module. For details on global constants, refer to the Data Dictionary for the application.

Constant Name
<None>

Module specific Lookup Tables Constants

(This is for lookup tables (arrays) with fixed values, same name as other tables)

Constant NameResolutionValueSoftware Segment
<None>


Functions/Macros used by the Sub-Modules

Library Functions / Macros

The library and functions / Macros that are called by the various sub modules are identified below,

  1. <None>

Data Hiding Functions

  1. <None>

Global Functions/Macros Defined by this Module

NOTE that all global functions in this module must be assembled in ARM mode. Therefore the .asm source file includes the .arm directive at the beginning of the file, applying the directive to all functions in the file.

Global Function #1

Function Name_coreEnableVfp_TypeDir.MinMaxUTP Tol.
Arguments PassedNone
Return ValueNone

Description

Enables VFP co-processor unit.

.def _coreEnableVfp_

.asmfunc

_coreEnableVfp_

mrc p15, #0x00, r0, c1, c0, #0x02

orr r0, r0, #0xF00000

mcr p15, #0x00, r0, c1, c0, #0x02

mov r0, #0x40000000

fmxr fpexc, r0

bx lr

.endasmfunc

Global Function #2

Function Name_coreInitRegisters_TypeDir.MinMaxUTP Tol.
Arguments PassedNone
Return ValueNone

Description

Initialize CPU Registers, including banked registers for all modes. This is required to be done at startup to ensure that both cores of the controller have identical starting register values to prevent a false trip of the core compare module. Included are all core registers as well as all floating point registers. Additionally, this function initializes the stack pointers for all modes of the uController. Therefore, this function needs to get executed prior to any stack usage and prior to any read usage of any core or floating point registers. The stack pointers are referenced by externally defined symbols (typically defined in the linker file) to allow for user configuration of the individual stack sizes.

.ref _StackUSER_

.ref _StackFIQ_

.ref _StackUND_

.ref _StackIRQ_

.ref _StackABORT_

.ref _StackSVC_

.def _coreInitRegisters_

.asmfunc

_coreInitRegisters_

; After reset, the CPU is in the Supervisor mode (M = 10011)

mov r0, lr

mov r1, #0x0000

mov r2, #0x0000

mov r3, #0x0000

mov r4, #0x0000

mov r5, #0x0000

mov r6, #0x0000

mov r7, #0x0000

mov r8, #0x0000

mov r9, #0x0000

mov r10, #0x0000

mov r11, #0x0000

mov r12, #0x0000

ldr sp, svcSp

; Switch to FIQ mode (M = 10001)

cps #17

mov r8, #0x0000

mov r9, #0x0000

mov r10, #0x0000

mov r11, #0x0000

mov r12, #0x0000

; Abort mode

cps #23

ldr sp, abortSp

mov lr, r0

; Undefined instruction mode

cps #27

ldr sp, undefSp

mov lr, r0

; FIQ mode

cps #17

ldr sp, fiqSp

mov lr, r0

; IRQ mode

cps #18

ldr sp, irqSp

mov lr, r0

; System mode

cps #31

ldr sp, userSp ; SYS mode shares stack with User mode

mov lr, r0

; Switch back to Supervisor Mode (M = 10011)

cps #19

fmdrr d0, r1, r1

fmdrr d1, r1, r1

fmdrr d2, r1, r1

fmdrr d3, r1, r1

fmdrr d4, r1, r1

fmdrr d5, r1, r1

fmdrr d6, r1, r1

fmdrr d7, r1, r1

fmdrr d8, r1, r1

fmdrr d9, r1, r1

fmdrr d10, r1, r1

fmdrr d11, r1, r1

fmdrr d12, r1, r1

fmdrr d13, r1, r1

fmdrr d14, r1, r1

fmdrr d15, r1, r1

bl next1

next1

bl next2

next2

bl next3

next3

bl next4

next4

bx r0

userSp .word _StackUSER_

svcSp .word _StackSVC_

fiqSp .word _StackFIQ_

irqSp .word _StackIRQ_

abortSp .word _StackABORT_

undefSp .word _StackUND_

.endasmfunc

Global Function #3

Function Name_esmCcmErrorsClear_TypeDir.MinMaxUTP Tol.
Arguments PassedNone
Return ValueNone

Description

Clear ESM CCM errors. This function is required for ERRATA DEVICE#140 workaround found in gladiator silicon revision A. It will clear all CCM error flags in the ESM status registers, clear the ESMKEY register to reset the ESM error pin state, clear the ESMH VIM interrupt request flag, and clear the core compare status register compare error flag.

.def _esmCcmErrorsClear_

.asmfunc

_esmCcmErrorsClear_:

ldr r0, ESMSR1_REG ; load the ESMSR1 status register address

ldr r2, ESMSR1_ERR_CLR

str r2, [r0] ; clear the ESMSR1 register

ldr r0, ESMSR2_REG ; load the ESMSR2 status register address

ldr r2, ESMSR2_ERR_CLR

str r2, [r0] ; clear the ESMSR2 register

ldr r0, ESMSSR2_REG ; load the ESMSSR2 status register address

ldr r2, ESMSSR2_ERR_CLR

str r2, [r0] ; clear the ESMSSR2 register

ldr r0, ESMKEY_REG ; load the ESMKEY register address

mov r2, #0x5 ; load R2 with 0x5

str r2, [r0] ; clear the ESMKEY register

ldr r0, VIM_INTREQ ; load the INTREQ register address

ldr r2, VIM_INT_CLR

str r2, [r0] ; clear the INTREQ register

ldr r0, CCMR4_STAT_REG ; load the CCMR4 status register address

ldr r2, CCMR4_ERR_CLR

str r2, [r0] ; clear the CCMR4 status register

bx lr

ESMSR1_REG .word 0xFFFFF518

ESMSR2_REG .word 0xFFFFF51C

ESMKEY_REG .word 0xFFFFF538

ESMSSR2_REG .word 0xFFFFF53C

CCMR4_STAT_REG .word 0xFFFFF600

CCMR4_ERR_CLR .word 0x00010000

ESMSR1_ERR_CLR .word 0x80000000

ESMSR2_ERR_CLR .word 0x00000004

ESMSSR2_ERR_CLR .word 0x00000004

VIM_INT_CLR .word 0x00000001

VIM_INTREQ .word 0xFFFFFE20

.endasmfunc

Global Function #4

Function Name_coreEnableRamEcc_TypeDir.MinMaxUTP Tol.
Arguments PassedNone
Return ValueNone

Description

Enable RAM ECC Support.

.def _coreEnableRamEcc_

.asmfunc

_coreEnableRamEcc_

mrc p15, #0x00, r0, c1, c0, #0x01

orr r0, r0, #0x0C000000

dmb

mcr p15, #0x00, r0, c1, c0, #0x01

isb

bx lr

.endasmfunc

Global Function #5

Function Name_coreDisableRamEcc_TypeDir.MinMaxUTP Tol.
Arguments PassedNone
Return ValueNone

Description

Disable RAM ECC Support.

.def _coreDisableRamEcc_

.asmfunc

_coreDisableRamEcc_

mrc p15, #0x00, r0, c1, c0, #0x01

bic r0, r0, #0x0C000000

dmb

mcr p15, #0x00, r0, c1, c0, #0x01

isb

bx lr

.endasmfunc

Global Function #6

Function Name_coreGetDebugStatusAndControlRegister_TypeDir.MinMaxUTP Tol.
Arguments PassedNone
Return ValueValue of DBGDSCR registeruint32FULLFULL

Description

Get contents of debug status and control register.

.def _coreGetDebugStatusAndControlRegister_

.asmfunc

_coreGetDebugStatusAndControlRegister_:

mrc p14, #0x00, r0, c0, c1, #0x00

bx lr

.endasmfunc

Global Function #7

Function Name_coreGetSecondaryAuxiliaryControlRegister_TypeDir.MinMaxUTP Tol.
Arguments PassedNone
Return ValueValue of Secondary Auxiliary Control Registeruint32FULLFULL

Description

Get contents of Secondary Auxiliary Control Register.

.def _coreGetSecondaryAuxiliaryControlRegister_

.asmfunc

_coreGetSecondaryAuxiliaryControlRegister_:

mrc p15, #0, r0, c15, c0, #0

bx lr

.endasmfunc

Global Function #8

Function Name_coreSetSecondaryAuxiliaryControlRegister_TypeDir.MinMaxUTP Tol.
Arguments PassedValue to be stored in Secondary Auxiliary Control Registeruint32FULLFULL
Return ValueNone

Description

Set contents of Secondary Auxiliary Control Register.

.def _coreSetSecondaryAuxiliaryControlRegister_

.asmfunc

_coreSetSecondaryAuxiliaryControlRegister_:

mcr p15, #0, r0, c15, c0, #0

bx lr

.endasmfunc

Global Function #9

Function Name_coreGetFPSCR_TypeDir.MinMaxUTP Tol.
Arguments PassedNone
Return ValueValue of FPSCR registeruint32FULLFULL

Description

Get contents of Floating Point Status and Control Register.

.def _coreGetFPSCR_

.asmfunc

_coreGetFPSCR_:

fmrx r0, FPSCR

bx lr

.endasmfunc

Local Functions/Macros Used by this MDD only

None

Software Module Implementation

Runtime Environment (RTE) Initial Values

This section lists the initial values of data written by this module but controlled by the RTE. After RTE initialization, the data in this table will contain these values.

DataValue
<None>

Initialization Functions

None

Periodic Functions

None

Fault Recovery Functions

None

Shutdown Functions

None

Interrupt Functions

None

Serial Communication Functions

None

Execution Requirements

Execution Sequence of the Module

(Describe in words relevant details about the execution sequence of the different sub modules.)

Execution Rates for sub-modules called by the Scheduler

This table serves as reference for the Scheduler design

Function NameCalling FrequencySystem State(s) in which the function is called
<None>

Execution Requirements for Serial Communication Functions

Function NameSub-Module called by (Serial Comm Function Name)
<None>

Memory Map Definition Requirements

Sub Modules (Functions)

This table identifies the software segments for functions identified in this module.

Name of Sub ModuleSoftware Segment
N/A

Local Functions

This table identifies the software segments for local functions identified in this module.

Name of Local FunctionSoftware Segment
None

Known Issues / Limitations With Design

None

Revision Control Log

Item #Rev #Change DescriptionDateAuthor Initials
11.0Initial Revision of MDD6/6/2013KMC
22.0Added disable RAM ECC function10/03/13LWW

8 - TMS570_Startup_SysStartup_MDD

Module --

High-Level Description

This module outlines the functionality of the system startup functions of the TMS570. This code is intended to be run starting at the reset vector.

Figures

Diagram – Function Data Sharing

This diagram shows all data that is shared between functions within the module.

No Shared Data


Variable Data Dictionary

For details on module input / output variable, refer to the Data Dictionary for the application. Input / output variable names are listed here for reference.

Module InputsModule Outputs
ResetCause_Cnt_EnumResetCause_Cnt_Enum

Module Internal Variables

This section identifies the name, range and resolutions for module specific data created by this module. If there are no range restrictions on the variable, the term “FULL” is placed into the table for legal range.

Variable NameResolution

Legal Range

(min)

Legal Range

(max)

Software Segment
<None>

User defined typedef definition/declaration

This section documents any user types uniquely used for the module.

Typedef NameElement NameValue
enum systemClockSourceSYS_OSC0
SYS_PLL11
SYS_EXTERNAL13
SYS_LPO_LOW4
SYS_LPO_HIGH5
SYS_PLL26
SYS_EXTERNAL27
SYS_VCLK9

Constant Data Dictionary

Calibration Constants

This section lists the calibrations used by the module. For details on calibration constants, refer to the Data Dictionary for the application.

Constant Name
<None>

Program(fixed) Constants

Embedded Constants

All embedded constants whose values are provided in Eng units will be evaluated to the equivalent counts by using the FPM_InitFixedPoint_m() macro within the #define statement.

Local

Constant NameResolutionUnitsValue
D_OTP1BITERRADDR_CNT_U321Counts0xF00803F4
D_OTP2BITERRADDR_CNT_U321Counts0xF00803FC
D_DPRAMSELECT_CNT_U321Counts0x4
D_SPRAMSELECT_CNT_U321Counts0x8
D_EFCAUTOLOADERROREN_CNT_U321Counts0x00040000
D_EFCINSTRUCTIONERROREN_CNT_U321Counts0x00080000
D_EFCINSTRUCTIONINFOEN_CNT_U321Counts0x00100000
D_EFCSELFTESTERROREN_CNT_U321Counts0x00200000
D_EFCSELFTESTDONE_CNT_U321Counts0x00008000
D_EFCSELFTESTERROR_CNT_U321Counts0x00004000
D_OUTPUTENABLE_CNT_U321Counts0x0003C000
D_SELFTESTERROR_CNT_U321Counts0x18
D_LPOTRIMVALUE_CNT_U321Counts((*(uint32*)0xF00801B4) & 0xFFFF0000)>>16
D_PLLSLIPMASK_CNT_U321Counts0x00000300
D_LOWBYTEMASK_CNT_U321Counts0x0000000FFUL
D_CURRENTLPOTRIMMASK_CNT_U321Counts0x00000FFFFUL
D_LPOMONLFTRIMMASK_CNT_U321Counts0xFFFFFF00UL
D_LPOMONHFTRIMMASK_CNT_U321Counts0xFFFF00FFUL
D_OTPRAMDEVICEADDR_CNT_U321Counts0xF0080148u
D_ESRAM5ENABLE_CNT_U321Counts0x01<<20
D_ESRAM6ENABLE_CNT_U321Counts0x01<<21
D_ESRAM8ENABLE_CNT_U321Counts0x01<<27

Global

This section lists the global constants used by the module. For details on global constants, refer to the Data Dictionary for the application.

Constant Name
D_SPRAMGRPSTMS_CNT_U32
D_DPRAMGRPSTMS_CNT_U32
D_CSDISCLRVAL_CNT_U32
D_CSVSTATMASK_CNT_U32
D_PCSPWRDWNCLR0VAL_CNT_U32
D_PCSPWRDWNCLR1VAL_CNT_U32
D_PSPWRDWNCLR0VAL_CNT_U32
D_PSPWRDWNCLR1VAL_CNT_U32
D_PSPWRDWNCLR2VAL_CNT_U32
D_PSPWRDWNCLR3VAL_CNT_U32
D_RAMPWRONINITMASKTMS_CNT_U32
D_RAMRESETINITMASKTMS_CNT_U32
D_PLLCTL1VAL_CNT_U32
D_FRDCNTLVAL_CNT_U32

Module specific Lookup Tables Constants

(This is for lookup tables (arrays) with fixed values, same name as other tables)

Constant NameResolutionValueSoftware Segment
None


Functions/Macros used by the Sub-Modules

Library Functions / Macros

The library and functions / Macros that are called by the various sub modules are identified below,

  1. <None>

Data Hiding Functions

  1. <None>

Global Functions/Macros Defined by this Module

Global Function #1

Function Name(Exact name used)TypeMinMaxUTP Tol.
Arguments Passed(if none, write None)
(Insert more rows for additional passed arguments)
Return Value(if no value returned, write N/A)

Description

(Place flowchart/design for local function)

Local Functions/Macros Used by this MDD only

Local Function DiagFailedReset

Function NameDiagFailedResetTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Function resetStartup

Function NameresetStartupTypeMinMaxUTP Tol.
Arguments PassedMemInitMask_Cnt_T_u32uint32FULLFULL
Return ValueN/A

Description

Local Function pwronStartup

Function NamepwronStartupTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Function afterSTC

Function NameafterSTCTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Function memInitialization

Function NamememInitializationTypeMinMaxUTP Tol.
Arguments PassedMemInitMask_Cnt_T_u32uint32FULLFULL
Return ValueN/A

Design Rationale

All VIM registers are cleared at the end of the startup initialization routine because the startup routine tests will set some interrupt flags during the testing (CCMSelfCheck).

Description

Local Function cpuSelfTest

Function NamecpuSelfTestTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Function setupPLL

Function NamesetupPLLTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Design Rationale

This function configures the PLL settings. These register settings assume 20MHz oscillator. Changes to these values will drive changes to these register values.

Description

Local Function efcCheck

Function NameefcCheckTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Function efcStuckZeroTestPassed

Function NameefcStuckZeroTestPassedTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueTestPassed_Cnt_T_lgcbooleanFALSETRUE0

Description

Local Function efcSelfTest

Function NameefcSelfTestTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description


Local Function periphInit

Function NameperiphInitTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Function checkEFCSelfTestPassed

Function NamecheckEFCSelfTestPassedTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueTestPassed_Cnt_T_lgcbooleanFALSETRUE0

Description

Local Function setupFlash

Function NamesetupFlashTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Design Rationale

The device ID is checked and if the gladiator revA part ID is detected, pre-emption is disabled. This is to account for errata DEVICE#145 of revA parts.

Description

Local Function trimLPO

Function NametrimLPOTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Function fmcBus2Check

Function NamefmcBus2CheckTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Function fmcECCcheck

Function NamefmcECCcheckTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Function mapClocks

Function NamemapClocksTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Function stcSelfCheck

Function NamestcSelfCheckTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Design Rationale

This function assumes a divide by two on the clock frequency will produce a frequency for the test to run at < 90MHz. For the current design, the clock frequency is 160MHz which will produce an 80MHz clock for this test.

Description

Local Function ccmSelfCheck

Function NameccmSelfCheckTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Function pbistSelfCheck

Function NamepbistSelfCheckTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Design Rationale

This function assumes a divide by two on the clock frequency will produce a frequency for the test to run at < 90MHz. For the current design, the clock frequency is 160MHz which will produce an 80MHz clock for this test.

Description

Local Function pbistRun

Function NamepbistRunTypeMinMaxUTP Tol.
Arguments PassedraminfoL_Cnt_T_u32uint32FULLFULL
algomask_Cnt_T_u32uint32FULLFULL
Return ValueN/A

Design Rationale

This function assumes a divide by two on the clock frequency will produce a frequency for the test to run at < 90MHz. For the current design, the clock frequency is 160MHz which will produce an 80MHz clock for this test.

Description

Local Function pbistStop

Function NamepbistStopTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Function Delay

Function NameDelayTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValueN/A

Description

Local Macro GetRamDomian1Enabled

Function NameGetRamDomian1EnabledTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValuebooleanFALSETRUE1

Description

Local Macro GetRamDomian2Enabled

Function NameGetRamDomian2EnabledTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValuebooleanFALSETRUE1

Description

Local Macro GetRamDomian3Enabled

Function NameGetRamDomian3EnabledTypeMinMaxUTP Tol.
Arguments PassedNone
Return ValuebooleanFALSETRUE1

Description

Software Module Implementation

Runtime Environment (RTE) Initial Values

This section lists the initial values of data written by this module but controlled by the RTE. After RTE initialization, the data in this table will contain these values.

DataValue
<None>

Initialization Functions

(Note: For multiple init functions, insert new headers at the “Header 2” level – subset of “5.1 Initialization Functions” and follow the same sub-section design shown below)

Init: _c_int00 / Startup

Design Rationale

This _c_int00 function is designed to be placed at the reset vector. Since this function needs to be compiled in arm mode, it immediately branches to the Startup() function which can optionally be compiled in thumb mode to allow memory optimizations. Since stacks are not available, the Startup() function needs to be defined as a Reset vector similar to _c_int00 so that the compiler does not try pushing data to the stack on entry to this function.

Texas Instruments had provided a recommended startup sequence which the design was based from. The document (spna106a.pdf) and accompanying source code (spna106a.zip) are located in the doc folder of this SWC. Note that SysStartup code primarily handles up to step 35 of spna106a (excluding step 12, 29, 30). Some of the notable deviations from the document include:

  • Addition of debugger connection detection to allow skipping initialization steps which interfere with debugging

  • Replacement of while(1) loops where failures occurred with Nexteer’s failure strategy summarized in section below

  • Use of configuration template headers to define initialization constants that may change from program to program

  • Handling of resets and use of “ResetCause” variable

  • Moving of mux initialization (Step 12 in spna106a) into application specific code (out of common initialization sequence)

  • Moving of SECDED logic check on RAM and Flash (Step 29, 30) into application specific code (out of common initialization sequence)

  • Some of the functions names were changed and the return type was changed to add clarity to the design (efcStuckZeroTest, checkEFCSelfTest)

Failed Initialization Diagnostic Strategy

A common strategy is used when diagnostics that are part of this initialization routine fail. In general, the “ResetCause” variable is set to an appropriate value, the nError pin is forced low, and a software reset is performed. The nError will put the controller into a known safe state. The software reset will allow the rest of the initialization tests to be bypassed, as well as reset the controller’s registers to a known state. The rest of the tests are bypassed to ensure the first failure is captured as the “ResetCause”, and the application can then evaluate the failure reason and set appropriate diagnostics codes (and communicate these on the communication bus if desired). Note that the registers getting reset will also reset the nError pin state, so forcing the nError pin low is also done when processing the software reset. Also note that for any of these diagnostics that fail, the general RAM banks will be initialized as part of the reset handling (as opposed to just initializing peripheral ram like most other resets).

Software Initiated Resets

For the two types of resets which can be initiated by software (CPU reset and SW reset), a strategy for setting the “ResetCause” variable has been used to allow for flexibility in adding new reset causes. A check is done to see if the current value of the “ResetCause” indicates a power-on reset. If this is the case, the initialization code assumes whatever code that initiated the reset did not explicitly indicate the reason for reset, and therefore the initialization code overwrites the value to the appropriate reset type (CPU or SW). If the reset value is anything other than power-on reset, the initialization code leaves the “ResetCause” as-is under the assumption that whatever code that initiated the reset set this cause specifically.

Errata Processing

The device ID is checked at power-on and if the gladiator revA part ID is detected, a _esmCcmErrorsClear_() function is called to handle DEVICE#140 errata processing.

Processing


Periodic Functions

None

Fault Recovery Functions

None

Shutdown Functions

None

Interrupt Functions

None

Serial Communication Functions

None


Execution Requirements

Execution Sequence of the Module

Execution Rates for sub-modules called by the Scheduler

This table serves as reference for the Scheduler design

Function NameCalling FrequencySystem State(s) in which the function is called
_c_int00()power on and during a resetN/A

Execution Requirements for Serial Communication Functions

Function NameSub-Module called by (Serial Comm Function Name)
<None>


Memory Map Definition Requirements

Sub Modules (Functions)

This table identifies the software segments for functions identified in this module.

Name of Sub ModuleSoftware Segment
_c_int00()

Local Functions

This table identifies the software segments for local functions identified in this module.

Name of Sub ModuleSoftware Segment
Startup
DiagFailedResetinline with calling function
resetStartup
pwronStartupinline with calling function
afterSTCinline with calling function
setupPLLinline with calling function
trimLPOinline with calling function
setupFlashinline with calling function
periphInitinline with calling function
mapClocksinline with calling function
ccmSelfCheckinline with calling function
stcSelfCheckinline with calling function
cpuSelfTestinline with calling function
efcCheckinline with calling function
efcSelfTestinline with calling function
efcStuckZeroTestPassedinline with calling function
checkEFCSelfTestPassedinline with calling function
fmcBus2Checkinline with calling function
fmcECCcheckinline with calling function
pbistSelfCheckinline with calling function
pbistRuninline with calling function
pbistStopinline with calling function
memInitializationinline with calling function


Known Issues / Limitations With Design

  1. (Item #1)


Revision Control Log

Item #Rev #Change DescriptionDateAuthor Initials
11Initial creation05/11/12LWW
22Updates for LPO Trim issue06/11/12LWW
33Updates to turn of PLL Slip and clock monitor resets in PLLCTL1 Register, added clearing of VIM interrupt requests before jumping into bootloader, added turning on DCAN parity if the memory is configured to be powered on prior to the memory initialization call07/13/12LWW
44Update SetUpPll code to check and recover from PLLSLIP and/or FBLSLIP. Modified SetUpPll code, Updated the TrimLPO function and added delay() function09/14/12BG, BDO
55Updated PLL settings for clock change to 150MHz10/12/12BWL
66Made PLL configurable and tied flash waitstate settings to frequency02/14/13LWW
77Made RAM pbist only run on banks enabled in OTP memory02/15/13BWL
88Correction for static register check02/15/13BWL
99Added call to Startup to allow compilation of file in thumb mode08/02/13LWW