Hello NXP Team,
We are developing a custom Firmware Over-The-Air (FOTA) solution for the S32K342 and would like guidance on the recommended flash architecture and boot flow.
MCU Details
Device: S32K342
PFlash: 2 MB
Bank 0: 1 MB
Bank 1: 1 MB
DFlash: 128 KB
Current Status
We are using UART as the firmware update interface.
So far, we have successfully:
Receive the firmware (.bin) over UART
Store the complete binary into flash memory
Verify that the received image is stored correctly
Our remaining challenge is implementing the bootloader architecture and application switching mechanism.
We would like clarification on the following:
1. Recommended FOTA Flash Layout
What is the recommended memory layout for an S32K342 dual-image FOTA implementation?
Specifically, we would like to know the recommended locations for:
Bootloader
Application Slot A
Application Slot B
Metadata / Boot flags
Version information
CRC
Rollback information
An example memory map with addresses would be extremely helpful.
2. Recommended Boot Flow
Could someone explain the complete boot sequence recommended by NXP?
For example:
Reset
Bootloader starts
Check boot flags
Select active application
Validate image (CRC/signature)
Jump to application
We would appreciate a flow diagram or explanation of the complete process.
3. Bootloader to Application Jump
For S32K342, is the standard Cortex-M7 jump sequence sufficient?
For example:
Read MSP from application base address
Read Reset_Handler from base + 4
Set MSP
Update VTOR
Jump to Reset_Handler
Are there any S32K342-specific requirements or initialization steps before transferring control?
4. Dual Application Images
If App A and App B are located at different flash addresses:
Should each application have its own linker script?
Or is there a recommended NXP approach for building dual-slot applications?
5. Flash Bank Usage
Since S32K342 has two 1 MB PFlash banks:
Is the recommended approach to:
Execute the bootloader from Bank 0
Program the new firmware into Bank 1
Switch execution after successful verification
Are there any Read-While-Write or erase/programming restrictions between the two PFlash banks?
6. Metadata Storage
Where is the preferred location to store:
Active image flag
Image validity
Firmware version
CRC
Rollback status
Should these be stored in:
Reserved PFlash
DFlash
Another dedicated region?
7. UART-Based FOTA
Since our update interface is UART, we would like to know the recommended workflow.
Is the following flow correct?
PC
│
UART
│
Bootloader receives .bin
│
Store firmware into inactive flash slot
│
Verify CRC
│
Update boot metadata
│
Reset MCU
│
Bootloader selects new image
│
Jump to application
Or does NXP recommend a different approach?
8. AB_SWAP vs Custom Bootloader
Is HSE AB_SWAP mandatory for production FOTA on S32K342?
Or is a fully custom bootloader with dual application slots also a supported and commonly used architecture?
If there are any application notes, reference projects, bootloader examples, or documentation specifically covering S32K342 FOTA, UART firmware updates, or dual-image bootloaders, we would greatly appreciate the references.
1. In case of S32K342, there’s only one possible setup for AB_SWAP. See “3.5.3.2 Illustrations of Flash memory layout in AB_SWAP” in HSE Firmware reference manual which can be downloaded from Documentation -> Secure files: https://www.nxp.com/products/S32K3
In your case, the most convenient and most common layout is:
It’s necessary to install AB_SWAP version of HSE firmware (the swap is a feature of HSE, it’s not possible to do that without HSE firmware). The firmware is installed to both partitions and it occupies last 176KB in both blocks as shown on the picture.
Because whole blocks are swapped, it’s necessary to have exact copy of the bootloader in both blocks. The rest is allocated for applications.
The code is always running from active block, so the bootloader and all applications are compiled for addresses in active block.
When bootloader updates an application, it programs the application to passive block, so there’s no problem with read-while-write issues during flash programming. Once the application is programmed, you can trigger HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK HSE service. After next reset, the partitions will be swapped and bootloader will jump to application as usual (to new application which is in active block now).
2. The flow is application dependent. In modern automotive applications, simple CRC-based validation is no longer considered sufficient. Integrity and authenticity of the software are typically ensured using Secure Boot mechanisms. On S32K3 devices, this is handled by the Hardware Security Engine (HSE), which performs cryptographic verification (e.g. signature-based) autonomously during boot. Production automotive systems are expected to leverage these hardware-backed security features rather than relying on CRC-only validation.
We provide Secure Boot application note including demo projects. It can be downloaded from:
https://www.nxp.com/products/S32K3
Application note can be found here:
Documentation -> Secure Files -> Secure Boot Application note v0.1.1.0 (AN744511)
Associated demo project can be downloaded here:
Design Resources -> Software -> Secure Files -> SecureBootAppNoteDemo (SW745310)
Other examples for secure boot can be found in HSE Demo Examples:
https://www.nxp.com/webapp/Download?colCode=S32K3_HSE_DemoExamples
There are examples for all three modes – advanced secure boot, basic secure boot and SHE secure boot. Advanced secure boot is recommended.
See Readme.md file which is included in all projects.
3. Yes, that’s standard jump sequence. It’s just highly recommended to de-initialize all resources initialized by bootloader before the jump.
4. As mentioned above, the code is always executed from active partition, so the application always uses the same linker file.
5. Already discussed above.
6. This is up to user. You can store the data behind the application image or to data flash.
7. For a production automotive use case, the proposed flow is generally correct from the data-transfer point of view, but as already mentioned, I would not recommend relying on CRC as the main validation mechanism.
In automotive applications, the received image is typically protected cryptographically - for example, the image may be encrypted and its authenticity/integrity is verified using a digital signature, not only by CRC.
Also, when using the HSE AB_SWAP mechanism, the bootloader does not simply select the new image by software metadata after reset. After the new image is programmed into the passive partition and successfully verified, the application/bootloader should call the HSE service HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK. This activates the passive block, so after reset the device boots from the newly activated partition.
8. HSE AB_SWAP is not strictly mandatory, but for a production automotive FOTA solution on S32K342 it is strongly recommended.
Implementing FOTA without HSE would mean you are not leveraging one of the key advantages of the S32K3 platform. The main benefit of these devices is the built-in support for A/B swap (partition remapping) handled by HSE. Without it, the bootloader would have to manage everything manually.
Specifically, without HSE AB_SWAP:
You would need to implement your own mechanism for selecting between A/B images
You would have to carefully manage the address space and link each application to different fixed locations
The swap between images would not be handled autonomously by the hardware, but entirely in your software
There is no alternative hardware-supported remapping mechanism available outside of HSE AB swap feature
In addition, you would lose the simplicity and robustness of Secure Boot integrated with AB_SWAP. With HSE, image activation, validation, and switching between partitions are handled in a much more controlled and efficient way, aligned with automotive security requirements.
In summary, doing this without HSE is possible, but it significantly increases complexity and removes key benefits of the platform.
You can take a look at “S32K3XX HSE and OTA Advance Training [TR744101]” which can be downloaded Documentation -> Secure files: https://www.nxp.com/products/S32K3
Regards,
Lukas