AN12422

S32G2 Boot Process

Rev. 4 — April, 2021 Application Note

Contents
1 Introduction 1 Introduction......................................1
2 Key terms used in the document.....1
S32G family is a high-performance vehicle network processor, combining
3 First Boot......................................... 2
CAN/LIN/FlexRay networking with high data rate Ethernet networking.
3.1 Power up......................................3
The target applications for S32G are: 3.2 BMODE configuration.................. 3
3.3 RCON configuration.....................3
• Central gateways and domain controllers connecting various networks 3.4 FUSE configuration......................4
and translating their protocols 3.5 Setting up the external memory for
• Firmware Over-The-Air (FOTA) masters controlling secure software Boot..............................................4
3.6 Image Vector Table (IVT).............4
image downloads and their distribution to the ECUs in the network
3.7 Self-test DCD............................... 6
• Secure key management 3.8 Device Configuration Data (DCD)
..................................................... 6
• Smart antennas
3.9 Application boot code image........7
• High-performance central compute nodes 3.10 BootROM..................................... 7
3.11 BootROM clock configuration...... 8
3.12 Image authentication and
2 Key terms used in the document decryption during secure boot..... 9
3.13 BootROM Fail Safe...................... 9
Boot Core – HSE_M7, the only CPU available when the hardware reset 3.14 BootROM at STANDBY Exit........ 9
sequence completes 4 Boot From external NVM.................9
BootROM – Firmware available in HSE ROM area that is executed by HSE_M7 4.1 Required hardware configuration
..................................................... 9
after reset.
4.2 QSPI boot.................................. 10
Non Secure boot – BootROM passes control to the user application residing 4.3 SD/MMC Boot............................ 10
outside HSE subsystem. 5 Serial Boot.....................................11
6 Bring up considerations.................12
Secure boot – BootROM passes control to the HSE firmware running on 7 References.................................... 12
HSE_M7. BOOT_SEQ bit in the IVT Boot configuration word defines if Secure 8 Revision history............................. 13
boot is to be enabled.
Boot mode pins (BMODE1 and BMODE2) – These pins are available to be configured by user to select the desired boot mode.
These are the first user inputs read by BootROM.
Serial boot - This boot mode allows application code to be downloaded to SRAM using LIN or CAN.
RCON - Boot configurations defined outside of the chip. RCON can be parallel (using 32 dedicated IOs) or serial (using I2C
based EEPROM).
External Flash – Non Volatile memory connected on QSPI, SD or MMC interface.
IVT (Image Vector Table) - The Image Vector Table (IVT) is the first image that the BootROM reads from the boot device. The
IVT contains the required data components like image entry point, pointer to Device Configuration Data (DCD) and other pointers
used by the BootROM during the boot process. The location of the IVT is the only fixed requirement by BootROM.
® ®
CM7_0 and A53_0 – Application cores that can be enabled by the BootROM. Either of CM7_0 or A53_0 are selected based on
BOOT_TARGET configuration in IVT Boot Configuration Word.
NXP Semiconductors
First Boot

3 First Boot
For a virgin device, the device can be forced to enter Serial boot mode using BMODE pins. In case boot from an external flash is
selected using BMODE and no image is present in the external flash, the device enters into serial boot mode after eight resets.
Refer to Serial Boot for further details.
Key steps for booting up the device:
1. Ensure power supply on the board
2. Ensure correct BMODE settings
3. Lauterbach (LTB) and T32 support for S32G2
Steps to load an application and execute directly from SRAM using LTB
1. Example T32 Script (S32G274A_CM7_0_Attach.cmm) to attach to S32G CM7_0 provided in the attachment section of
the AN
2. Custom application (constraint – SRAM size of 8MB), use data.load.elf <File_name.elf> from the LTB window
Steps if Serial boot is required:
1. Application binary to download (Constraint – SRAM size of 8 MB)
2. Tool to transfer binary on Serial (UART/CAN) port. Use S32 Design Studio (S32DS) flash tool can also be used for
serial download
3. Hardware bus connection for the serial interface to target board
Steps if required to boot from QSPI:
1. Prepare binary image using S32DS IVT configurator
2. Use S32DS flash tool to program the QSPI flash. The tool is available with S32DS installation at directory
<installation_directory> \S32DS.3.4\S32DS\tools\S32FlashTool\GUI\s32ft.exe
3. Select the target as S32G274A, Algorithm as QSPI flash component on hardware and COM port as per individual
machine configuration
4. Follow the instructions available with S32DS flash tool (S32_Flash_Tool_User_Guide.pdf in the S32DS installation
directory) for further steps
5. Configure RCON as per recommendation in Boot Config Word setting
6. Configure BMODE to ‘10’ (See table 1 below for further details)
7. The device will boot from QSPI after the next reset
Steps if required to boot from SD/MMC:
1. Prepare binary image using S32DS IVT configurator
2. Use S32DS flash tool to program the SD/MMC. The tool is available with S32DS installation at directory
<installation_directory> \S32DS.3.4\S32DS\tools\S32FlashTool\GUI\s32ft.exe
3. Select the target as S32G274A, Algorithm as SD/MMC component on hardware and COM port as per individual
machine configuration
4. Follow the instructions available with S32DS flash tool for further steps
5. Alternatively, a utility application like Win32DiskImager can also be used to format and write raw binary into the SD card.
Plug in the SD card into the target board
6. Configure BMODE to ‘10’ (See table 1 below for further details)
7. Configure RCON as per recommendation in Boot Config Word setting
8. The device will boot from SD/MMC after the next reset

S32G2 Boot Process , Rev. 4, April, 2021

Application Note 2 / 14
NXP Semiconductors
First Boot

3.1 Power up
The user must ensure that all power supplies required for operation of S32G2 are up in the sequence as mentioned in the S32G2
datasheet. Also, the supply limits for all power pins mentioned in the device datasheet must be respected at all times.

3.2 BMODE configuration

BMODE1 and BMODE2 pins are the first user inputs required by the device to configure the BootROM into correct state. These
pins are sampled by the BootROM to decide the boot configuration of the device.
For the first unprogrammed samples, it is recommended to set BMODE pins for serial boot operation. Setting the boot mode to
serial configuration also ensures that the HSE_M7 SWT does not timeout. BootROM disables the SWT in Serial boot mode. for
device lifecycle CUST_DEL. For lifecycle later than CUST_DEL a timeout of 60 seconds is applicable. Serial boot is only available
if the DIS_SER_BOOT fuse bit is not blown.

Table 1. BMODE configuration

FUSE_SEL BMODE1 BMODE2 Boot Mode Available Use Case

boot interfaces

0 0 0 Serial Boot, Serial Production config

XOSC configured communication for virgin devices
in differential interfaces: LIN
bypass mode (UART) and CAN

0 1 Serial Boot, XOSC Serial

in Crystal mode or communication
Bypass mode interfaces: LIN
(UART) and CAN

1 0 Boot from external Memory interfaces: Development

memory using QSPI, SD card, config
RCON MMC, eMMC
configurations

1 0 X Boot from external Memory interfaces: Production config

memory using QSPI, SD card, for programmed
Fuse configuration MMC, eMMC devices

1 0 Serial Boot Serial Debug of

communication programmed
interfaces: LIN device
(UART) and CAN

X 1 1 Reserved

3.3 RCON configuration

During development phase, developer may need to try different boot configurations before the final boot strategy is selected. For
instance the QSPI flash may not be programmed on the first day and setting boot configuration to QSPI flash may result in no
action from BootROM and subsequent resets. Thus a mechanism is required wherein user can download their application directly
to internal SRAM. Serial boot can be used in such cases which may be required to be modified to boot from an external NVM (QSPI
flash or SD card) at a later stage. In such scenario, using Fuses may not be a viable options since a fuse once blown cannot be
reverted or changed. For such scenarios, RCONs are provided that can be used in lieu of the boot fuses, BOOT_CFG1. The 32 bits
of fuses are mimicked with 32 parallel GPIO lines (parallel RCON) or through a serial EEPROM (serial RCON), that are sampled
during the Functional Reset sequence.
Parallel RCONs can be used by connecting 32 DIP switches on the 32 RCON I/Os and can be set to different values as per the
development requirement.

S32G2 Boot Process , Rev. 4, April, 2021

Application Note 3 / 14
NXP Semiconductors
First Boot

To use serial RCON, RCON8 pin must be pulled HIGH. The BootROM then assumes that a serial EEPROM is connected on the
I2C port (RCON7 and RCON8). The 32 reset configuration bits are then fetched from the external EEPROM (first 4 bytes from
offset 0x0 of the device) as part of the Boot process.
The address of the EEPROM device should be set as 0xA0.
FUSE_SEL fuse must be blown in case S32G2 is required to be forced to boot using Fuses. The BOOT_CFGn fuses must be
blown prior to setting the FUSE_SEL fuse.

3.4 FUSE configuration

Fuse map table with details on all available fuses is attached with the device reference manual (RM).
The fuse map table shows three BOOT_CFG_LOCK fuses. BootROM uses these three fuses to configure it’s operations. RCON
settings must be seen as a development time substitute for BOOT_CFG1 fuse only. The configuration of RCON pads on the
hardware should also be done in accordance with the bit field description of BOOT_CFG1 fuse.
Bits 7-5 in the BOOT_CFG1 are the external memory selector pins.

Figure 1. BOOT_CFG1 memory selector bits

The rest of the bits in the three boot configuration fuses are used for configuration of external memory interface or configuration
of serial boot supporting peripherals. BOOT_CFG2 and BOOT_CFG3 fuse words can only be set by fuse programming.

3.5 Setting up the external memory for Boot

Any external NVM memory interface selected by means of Fuses/RCON, should have the images programmed in a specific way
for the BootROM to be able to process the image. The programmed image must have the following sections:
• Image Vector Table (IVT)
• Device Configuration Data (DCD)
• Self-Test DCD
• HSE_H Firmware
• Application Boot Code Image
S32DS IDE comes with configurator tools that can be directly used to generate these images. For further information on the same,
please check the help manuals in S32DS.

3.6 Image Vector Table (IVT)

The IVT is the first image read by BootROM from the boot device. As such there is a precise requirement to place the IVT in
a predefined location of the external memory used/programmed. For QSPI boot, the BootROM expects the IVT to be placed at
the 0h location of external memory. For SD/MMC/eMMC boot, the IVT should be placed at 0x1000 offset[1]. Pointers to all other
requirements/images is then parsed by the BootROM from IVT. IVT table structure is shown below.

[1] For Rev 1 Silicon, in case of SD/MMC/eMMC boot the BootROM expects the IVT to be placed at 0h location of the
external NVM.

S32G2 Boot Process , Rev. 4, April, 2021

Application Note 4 / 14
NXP Semiconductors
First Boot

Table 2. IVT image structure

Address Size (in Name Comment

Offset Bytes)

0x0 4 IVT Header Header showing the start of IVT

0x04 4 Reserved Reserved

0x08 4 Self-Test DCD pointer Pointer to the start of the configuration data used for BIST

0x0C 4 Self-Test DCD Backup pointer Pointer to the start of the backup configuration data used
for BIST

0x10 4 DCD Pointer Pointer to the start of DCD configuration data

0x14 4 DCD Backup pointer Pointer to the start of backup DCD configuration data

0x18 4 HSE FW Flash Start pointer Pointer to the start of the HSE_H firmware in flash memory

0x1C 4 HSE FW Backup Flash Start pointer Pointer to the start of the backup HSE_H firmware in
flash memory

0x20 4 Application Flash Start pointer Pointer to the start of the application code in flash memory

0x24 4 Application Backup Flash Pointer to the start of the backup application code in
Start pointer flash memory

0x28 4 Boot Configuration Word Configuration data used to select the boot configuration

0x2C 4 Life-Cycle Configuration Word Configuration data used for advancing Life-Cycle

0x30 4 Reserved Reserved

0x34 32 Reserved Reserved

0x54 156 Reserved Reserved

0xF0 16 GMAC GMAC of first 240 bytes of IVT image structure.

NOTE
Ensure that the Life cycle configuration word at offset 0x2c is set to '0'.

The IVT image Header is a fixed value (0xD1010060 – shown here in Big Endian format) for S32G2 and is shown in the device
RM also.
The IVT Boot Configuration Word can be used to select:
1. The boot core - either M7_0 or A53_0 as the boot core (bits 0-1),
2. Enable/Disable boot target watchdog (bit2) (SWT0 can be only configured)
3. Secure boot mode - configures between the secure and non-secure boot mode (bit 3)

S32G2 Boot Process , Rev. 4, April, 2021

Application Note 5 / 14
NXP Semiconductors
First Boot

Figure 2. IVT boot configuration word

The IVT Life-cycle configuration word can be used to advance the lifecycle of the device to OEM_PROD (bit 0) or IN_FIELD (bit
1). Life cycle once advanced cannot be reverted back.

Figure 3. IVT Life-cycle configuration word

NOTE
Care must be taken that the values for both configuration word are set appropriately (either 0 or 1 as required). Not
writing to these words in IVT may be incorrectly interpreted as ‘1’ by the BootROM thereby implicating incorrect
settings. Some of these settings require fuse bits to be blown that may result in irrevocable changes to the
device settings.

BootROM supports concept of backup image for Self-test DCD, DCD, Application and HSE_FW. For each type of program image,
BootROM first tries to execute its primary image if IVT points to a valid location. Only 0x0 is considered an invalid location. If
primary image points to 0x0 or primary image header does not match with image required header or authentication fails, wherever
applicable, BootROM tries to execute backup image pointed by IVT.

3.7 Self-test DCD

BootROM executes self-test only when coming out of POR, and if no previous self-test has been run (i.e. ST_DONE is not set in
RGM). For self-test to be run by BootROM, the self-test DCD section in IVT must also be programmed. Self-test DCD follows the
same structure as other DCD defined in Device Configuration Data (DCD). The maximum size of the self-test DCD image can be
8192 Bytes.

Table 3. Self-test header

Byte 0 Byte 1 Byte 2 Byte 3

TAG = D3h Length Version = 60h

Execution of Self-test is always followed by a reset. The recommended Self-test DCD is provided as a binary with Safety Software
Framework (SAF) release.

3.8 Device Configuration Data (DCD)

DCD is the configuration information contained in the DCD Image, which BootROM interprets to configure various peripherals on
the device. DCDs can be used to configure any peripheral before the control is handed over to application. The maximum size of
DCD image can be 8192 bytes.

S32G2 Boot Process , Rev. 4, April, 2021

Application Note 6 / 14
NXP Semiconductors
First Boot

Figure 4. DCD image structure

The header structure for DCD is as follows:

Table 4. DCD header

Byte 0 Byte 1 Byte 2 Byte 3

TAG = D2h Length Version = 60h

3.9 Application boot code image

For nonsecure boot configuration, the application image pointed to by IVT should comply with the below structure.

Table 5. Application boot image structure

Address Size (in Bytes) Name Comment

Offset

0x0 4 Image header Header to signify start of application image.

0x04 4 RAM Start pointer Pointer to the RAM location BootROM uses to copy the code.

0x08 4 RAM entry pointer Pointer to start of code execution. This pointer should be within the
section of SRAM where the application image is downloaded.

0x0C 4 Code length Length of code section of the image.

0x10 48 Reserved

0x40 Code_length Code Code can be any size up to the max size of System SRAM.

The Image header should be as shown below:

Table 6. Application header

Byte 0 Byte 1 Byte 2 Byte 3

TAG = D5h Reserved Version = 60h

3.10 BootROM
BootROM is the first software that runs on S32G2 after any reset. It is placed in an internal ROM (accessible only to HSE_M7) and
is executed by HSE_M7. After the execution of the BootROM, the control is passed either to HSE FW (in case of secure boot) or
to customer application (in case of non-secure boot).

S32G2 Boot Process , Rev. 4, April, 2021

Application Note 7 / 14
NXP Semiconductors
First Boot

Figure 5. Non secure boot flow

Figure 6. Secure boot flow

BootROM relies on user inputs in the form of BMODE pins, RCON and Fuse configurations to decide and enable the appropriate
boot mode.

Figure 7. Boot Selection Target, Interfaces and Mode

3.11 BootROM clock configuration

FIRC is the default system clock after Reset. BootROM configures CORE_PLL DFS (targeting 400 MHz) over FIRC. In case PLL
lock is not achieved, BootROM continues with FIRC as the system clock.

S32G2 Boot Process , Rev. 4, April, 2021

Application Note 8 / 14
NXP Semiconductors
Boot From external NVM

In case of non-secure boot, BootROM configures the system clock to FIRC before handing the control to the application code.
In case of secure boot, BootROM passes control to HSE FW with system clock as CORE_PLL DFS. The HSE FW does not change
any clock settings before handing over the control to application.
Refer to S32G2_BOOT_Settings.xlsx attached with the device RM for more details on clock and other peripheral configurations
touched by BootROM.

3.12 Image authentication and decryption during secure boot

BootROM has the responsibility to authenticate, decrypt and load HSM Firmware when performing a secure boot operation. The
authentication scheme followed by BootROM to accomplish secure boot is shown in table below.

Table 7. Authentication scheme

Image Authentication Scheme

IVT AES-256 GCM

DCD AES-256 GCM

Self-Test DCD AES-256 GCM

Serial Application Image RSA Signature Verification

HSE Firmware Image AES-256 GCM

3.13 BootROM Fail Safe

Any kind of exception occurring during boot phase would result in BootROM issuing a functional reset. If the number of successive
functional reset get to a value of 8 or beyond, BootROM enters Serial Boot mode.
Care must be taken by the application code to monitor and clear the reset sources issued by the application. Failure to do so may
result in BootROM incorrectly identifying these resets as ones generated during boot phase and may result in BootROM forcing
the system to Secure boot mode even when the application boot was possible.

3.14 BootROM at STANDBY Exit

BootROM supports booting from STANDBY IVT or full boot at every STANDBY mode exit. The decision to boot either from
STANDBY IVT or full boot is taken based on the wakeup source and its configuration in WKPU_WBMSR register. Full boot
configuration is similar to device coming out of Reset.
STANDBY IVT has the same format as full boot/Reset IVT except that it’s placed at the first location of STANDBY RAM, i.e.
0x24000000. Only DCD and application boot are supported, and no data fetch from external NVM is supported. Also, secure boot
is not supported in case of STANDBY IVT. All pointers in STANDBY IVT must point to addresses within STANDBY RAM.
In case more than one wakeup sources are latched, full boot is performed if even one of the wakeups is configured for full boot.

4 Boot From external NVM

4.1 Required hardware configuration

Boot mode and RCON pins needs to be configured for BootROM to understand and configure the required boot device.

S32G2 Boot Process , Rev. 4, April, 2021

Application Note 9 / 14
NXP Semiconductors
Boot From external NVM

Table 8. BMODE pin settings for external NVM

FUSE_SEL BMODE0 BMODE1 Boot Mode

Development phase 0 1 0 Boot from external memory using RCON configuration

Production phase 1 0 x Boot from external memory using Fuse configuration

Configuration required on S32G-PROCEVB-S:

1. SWT14 -> 1 ON, SWT14 -> 2 OFF
2. SWT15 -> 1 OFF SWT15- > 2 OFF
BOOT_CFG1 (using RCON or fuse depending on FUSE_SEL), BOOT_CFG2 and BOOT_CFG3 example settings are provided
in the xls attached.

4.2 QSPI boot

BootROM performs QSPI controller configuration in two phases:
1. Initial configuration phase: Configure QSPI controller at 40 MHz in 1-bit mode for Quad and Octal flash and 8-bit mode for
Hyperflash. Read user-provided Flash reconfiguration data from offset 0x200 of the flash.
2. Final configuration phase: Program QSPI clock source and QSPI controller as per
details provided in reconfiguration data. Example reconfiguration binaries for some external
flash devices is provided with the latest S32DS release at path (installation
directory)\eclipse\mcu_data\processors\S32G274A_Rev2\PlatformSDK_S32G_2020_12\quadspi\default_boot_images.

NOTE
In Rev 1 Silicon (mask 1N92V), for application size greater than 1 MB, QSPI reconfiguration parameters must be
programmed. For Rev 2 Silicon (mask 0P77B), this limitation has been fixed.

4.2.1 Clock configuration

In Initial configuration phase, BootROM clocking scheme for QSPI operations depends upon PLL lock status. BootROM tries to
lock the PERIPH PLL and PERIPH DFS1 for generating QSPI_1X_CLK of 40 MHz. If PLL-DFS are locked successfully at 40 MHz
then clock is switched to PLL otherwise, QSPI clock is derived from FIRC, resulting QSPI_1X_CLK as FIRC/2.
In Final configuration phase, QSPI read operations clock requirements are derived by clock provided by user in QSPI
Re-Configuration data. In case of failure to generate the required clock, BootROM skips the configuration provided and continues
read operations with default configuration and QSPI clock derived from FIRC.

4.2.2 Boot Config Word setting

Xls attached

NOTE
The QuadSPI POR Delay value needs to be programmed as per external flash requirement. These are not
automatically applied at standby exit. HSE provides a service to enable the POR delay at next boot after standby
exit. Please refer to HSE manuals for further details.

4.3 SD/MMC Boot

Only 3.3 V High Speed and Default Speed data rate operations are supported while booting from SD cards. BootROM does not
support switching to 1.8V for SDR modes.

S32G2 Boot Process , Rev. 4, April, 2021

Application Note 10 / 14
NXP Semiconductors
Serial Boot

NOTE
For Application Boot via SD interface, when BOOT_SEQ == 0, RAM start pointer for application should not point
between 0x34008050 to 0x34008200. This address range is used by BootROM for internal operation during boot
via "SD.interface". BootROM also uses 4 KB of SRAM memory starting 0x343FF000 for ADMA descriptors in case
of μSDHC boot. Application image header should not point to this location in case of μSDHC boot.

4.3.1 Clock Configuration

BootROM tries to lock the Peripheral PLL-DFS and in case of success, switches the SDHC_CLK from FIRC to PLL.

4.3.2 Boot Config Word setting

Xls attached

4.3.3 μSDHC supported data rates

Table 9. μSDHC supported data rates

Speed Modes Max Data Transfer Rate Clock Speed Signal Voltage

Identification Speed NA ~380 kHz 3V3

Default Speed 12.5 MB/s 25 MHz 3V3

High Speed 25 MB/s 50 MHz 3V3

BOOT_CFG1[19] controls selection of Default Speed or High Speed mode in case SD card is used over μSDHC interface.

4.3.4 MMC supported data rates

Table 10. MMC supported data rates

Speed Modes Max Data Transfer Rate Clock Speed Bus Width

Normal Speed 25 MB/s 25 MHz 1, 4, 8 bits

High Speed 50 MB/s 50 MHz 1, 4, 8 bits

High Speed DDR 100 MB/s 50 MHz 4, 8 bits

BOOT_CFG1[22:19] controls selection of Speed modes in case MMC/eMMC card is used over μSDHC interface.

5 Serial Boot
Serial Boot mode enables application code to be downloaded to SRAM through serial peripherals. The two primary use cases for
serial boot are:
• End-of-line flash memory and fuse programming
• Recovery of chips that fail to boot correctly (nonresponsive modules)
This feature can be disabled by blowing fuse DIS_SER_BOOT.
Serial Boot mode is entered via the BMODE input pins. The device also enters serial boot mode if the Functional reset counter
reaches a value >= 8. The functional reset may be result of any of the errors encountered during BootROM execution for e.g.,
software programming errors during development, flash memory failure, PCB failure during production, timeout due to failure of

S32G2 Boot Process , Rev. 4, April, 2021

Application Note 11 / 14
NXP Semiconductors
Bring up considerations

hardware modules, authentication failure during secure boot, exceptions during BootROM execution, unavailability of a valid boot
image in the selected NVM and so on.
In Serial Boot mode, BootROM continuously polls for activity on any of the available interfaces:
• CAN
• LIN (UART)
In CUST_DEL life cycle, BootROM does not configure any watchdog when polling on serial interfaces. However for life cycles
OEM_PROD and IN_FIELD, HSE SWT is activated with a timeout of 60 seconds.
The application should also specially take care that once serial download is complete, BootROM enables the SWT_0 with its
default configuration. It is now the responsibility of the application to take care of servicing the watchdog.
Please refer to chip RM for further details.

6 Bring up considerations
S32G2 boot architecture is designed in such a way that it always expects the device to be in serial boot mode when none of
the NVM devices have a verified application in it. Once in serial boot mode, the device expects to receive the application on
UART/CAN interfaces as defined in the Serial boot. For simple tests, the developer or tester can even download an application
to SRAM directly however with a clear limitation that BootROM may interfere with UART/CAN settings.
To understand the boot architecture better, BMODE configurations needs to be revisited.
In a production line scenario, for a virgin device the FUSE_SEL would be available in reset state (depicted by 0 in the Table 1) and
setting BMODE pins to serial boot would allow downloading the complete application image. Flash tools working on serial boot
mode and provided with S32 Design Studio (S32DS) can also be used. As a next step, the FUSE_SEL should be blown such that
the boot configurations are picked up from BOOT_CFG fuses rather than external RCON. After FUSE_SEL is set to 1, the BMODE
configurations earlier depicting serial boot now automatically configures the device to boot from external NVM, refer to Table 1.
The type of NVM is configured based on the BOOT_CFG1 fuse word.
During development phases, it is always recommended to configure the BMODE pins to put device in serial boot mode
when erasing/programming the external NVM. If the device is configured to boot from external NVM and the NVM is being
erased/programmed, then there are possibilities that an interruption in flash erase/program operation may bring irrevocable
changes to the state of the device. For instance, there can be a scenario wherein the IVT header and few other entries of the IVT
table get programmed but the Life cycle configuration word remains in erased state (0xFFFFFFFF) and the flash operation gets
interrupted. In such a case, after next reset the device will look for boot configurations and on finding it to be a ‘boot from NVM’
it would start executing from the NVM. On locating the right IVT header it would start feeding the BootROM with the parameters
in the IVT table and would also feed the unintentional Lifecycle advancement command. The BootROM would then advance
the Lifecycle of the device and the device may no longer be accessible through the debugger. To avert such an issue, the
recommendation of keeping device in serial boot through BMODE pins is provided during programming of NVM and the user must
always verify external flash for the availability of right content. This should not be confused with the serial boot entry when device
is configured to boot from external NVM and no legitimate image is found in the NVM.

7 References
S32G2 Hardware Design Guidelines (S32G2HDG)
S32G2 RM Rev 2
S32G-PROCEVB-S Schematic

S32G2 Boot Process , Rev. 4, April, 2021

Application Note 12 / 14
NXP Semiconductors
Revision history

8 Revision history
Table 11. Revision history

Revision number Date Substantive changes

0 September, 2019 Initial release

1 October, 2019 • Changed Secure boot flow.

• Added table titles in Table 9 and
Table 10.
• In Table 10 changed the unit from
kHz to MHz in Clock speed for High
Speed mode.

2 June, 2020 • Updated First Boot.

• Updated BMODE configuration.
• Updated the note in Setting up the
external memory for Boot.
• updated text in Image Vector Table
(IVT).
• Updated note in QSPI boot.

3 March, 2021 • Added Serial Boot.

• Removed Ethernet boot and its
references from the document.
• Updated QSPI POR delay note.

4 April, 2021 • Added Bring up considerations.

• In MMC supported data rates,
updated the Speed modes.

S32G2 Boot Process , Rev. 4, April, 2021

Application Note 13 / 14
How To Reach Us Information in this document is provided solely to enable system and software implementers
to use NXP products. There are no express or implied copyright licenses granted hereunder
Home Page:
to design or fabricate any integrated circuits based on the information in this document. NXP
nxp.com reserves the right to make changes without further notice to any products herein.
Web Support: NXP makes no warranty, representation, or guarantee regarding the suitability of its products
nxp.com/support for any particular purpose, nor does NXP assume any liability arising out of the application
or use of any product or circuit, and specifically disclaims any and all liability, including
without limitation consequential or incidental damages. “Typical” parameters that may be
provided in NXP data sheets and/or specifications can and do vary in different applications,
and actual performance may vary over time. All operating parameters, including “typicals,”
must be validated for each customer application by customer's technical experts. NXP does
not convey any license under its patent rights nor the rights of others. NXP sells products
pursuant to standard terms and conditions of sale, which can be found at the following address:
nxp.com/SalesTermsandConditions.

While NXP has implemented advanced security features, all products may be subject to
unidentified vulnerabilities. Customers are responsible for the design and operation of their
applications and products to reduce the effect of these vulnerabilities on customer’s applications
and products, and NXP accepts no liability for any vulnerability that is discovered. Customers
should implement appropriate design and operating safeguards to minimize the risks associated
with their applications and products.

NXP, the NXP logo, NXP SECURE CONNECTIONS FOR A SMARTER WORLD, COOLFLUX,
EMBRACE, GREENCHIP, HITAG, I2C BUS, ICODE, JCOP, LIFE VIBES, MIFARE, MIFARE
CLASSIC, MIFARE DESFire, MIFARE PLUS, MIFARE FLEX, MANTIS, MIFARE ULTRALIGHT,
MIFARE4MOBILE, MIGLO, NTAG, ROADLINK, SMARTLX, SMARTMX, STARPLUG, TOPFET,
TRENCHMOS, UCODE, Freescale, the Freescale logo, AltiVec, C‑5, CodeTEST, CodeWarrior,
ColdFire, ColdFire+, C‑Ware, the Energy Efficient Solutions logo, Kinetis, Layerscape, MagniV,
mobileGT, PEG, PowerQUICC, Processor Expert, QorIQ, QorIQ Qonverge, Ready Play,
SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid, Airfast, BeeKit,
BeeStack, CoreNet, Flexis, MXC, Platform in a Package, QUICC Engine, SMARTMOS, Tower,
TurboLink, UMEMS, EdgeScale, EdgeLock, eIQ, and Immersive3D are trademarks of NXP
B.V. All other product or service names are the property of their respective owners. AMBA,
Arm, Arm7, Arm7TDMI, Arm9, Arm11, Artisan, big.LITTLE, Cordio, CoreLink, CoreSight, Cortex,
DesignStart, DynamIQ, Jazelle, Keil, Mali, Mbed, Mbed Enabled, NEON, POP, RealView,
SecurCore, Socrates, Thumb, TrustZone, ULINK, ULINK2, ULINK-ME, ULINK-PLUS, ULINKpro,
µVision, Versatile are trademarks or registered trademarks of Arm Limited (or its subsidiaries)
in the US and/or elsewhere. The related technology may be protected by any or all of patents,
copyrights, designs and trade secrets. All rights reserved. Oracle and Java are registered
trademarks of Oracle and/or its affiliates. The Power Architecture and Power.org word marks and
the Power and Power.org logos and related marks are trademarks and service marks licensed
by Power.org.
© NXP B.V. 2021. All rights reserved.
For more information, please visit: http://www.nxp.com
For sales office addresses, please send an email to: [email protected]

Date of release: April, 2021

Document identifier: AN12422