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
