S32K342 FOTA Bootloader Architecture Guidance Required (UART-Based Update) 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. Thank you for your support. S32K3 S32DS-ARM Re: S32K342 FOTA Bootloader Architecture Guidance Required (UART-Based Update) Hi @bavinkumar_02
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
View full article
