S32K328 HSE-B: Recommended Architecture for A/B Swap using Mem_43_INFLS (without Vector FOTA) Hello NXP Team, We are currently in the design and implementation phase of adding OTA A/B swap support to an existing application running on S32K328. This is an initial implementation where we are extending the existing software with OTA capability rather than integrating a complete FOTA framework. Current Environment MCU: S32K328 (8 MB P-Flash) AUTOSAR Stack: Vector MICROSAR RTD: S32K3_RTD_6_0_0_QLP04_D2508_ASR_REL_4_7_REV_0000_20250822 Binary transfer interface: UART Image activation service: HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK HSE A/B swap is enabled via RTD configuration The OTA binary is received over UART by a custom OTA CDD. Our current Vector configuration contains MemAccM only for NvM/Fee (D-Flash). There is no MemAccM configuration for programming the application P-Flash, and we are not using Vector OTA/FOTA. Therefore, we are considering using Mem_43_INFLS from the OTA CDD to erase and program the inactive application flash directly. We would appreciate guidance on the following points. 1. Recommended approach Is Mem_43_INFLS the recommended low-level driver for managing OTA image programming in an A/B swap setup when not using Vector’s OTA/FOTA package? Or should MemAccM be extended to cover P‑Flash programming even for custom OTA implementations? 2. Inactive flash block addressing After enabling HSE A/B swap: Is the inactive application P‑Flash block always accessed via fixed physical addresses defined in the memory layout? Or does HSE provide any logical mapping or abstraction for the passive block? 3. Preconditions for activation What are the mandatory preconditions for successful execution of HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK? For example: Image header format Metadata requirements Alignment constraints Authentication / signature requirements Flash state or attributes 4. Flash controller concurrency Does the C40 flash controller on S32K328 support concurrent operations between D‑Flash (Fee/NvM) and P‑Flash (inactive block)? If not, what is the recommended synchronization strategy: Application-level scheduling RTD driver arbitration MemAccM usage 5. Recommended architecture Is the following architecture aligned with NXP recommendations? UART ↓ Custom OTA CDD ↓ Mem_43_INFLS (erase/write inactive P‑Flash) ↓ Image verification ↓ HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK ↓ System reset ↓ HSE/BAF activates the passive block We are specifically looking for guidance on whether this lightweight approach is appropriate and compliant with HSE requirements. If there are any application notes, RTD examples, or reference implementations for custom OTA with HSE A/B swap, we would greatly appreciate your guidance. Thank you for your support. Best regards, Venkatesh KV #s32k328 Re: S32K328 HSE-B: Recommended Architecture for A/B Swap using Mem_43_INFLS (without Vector FOTA) Hi @venkatesh-kv
1. A custom OTA implementation can use Mem_43_INFLS directly to erase and program the passive partition. Whether MemAccM should be extended is an architectural decision and mainly depends on whether a common flash access and arbitration layer is desired within the application.
2. The passive application image is normally programmed using its physical P-Flash address range. HSE does not provide a dedicated logical addressing abstraction for the passive block. The application/bootloader is responsible for writing the new image to the inactive partition, after which HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK can be used to make that partition active on the next reset.
3. If secure boot is used, the signatures should be updated accordingly (depending on secure boot mode and other settings), so new application can be successfully authenticated and executed after next reset. Older version of HSE firmware required super user rights to execute service HSE_SRV_ID_ACTIVATE_PASSIVE_BLOCK. This has been downgraded to normal user rights in firmware versions 0.2.55.0 and newer.
4. Only one flash operation can run at a time. The implementation of flash access arbitration is left to the application architecture. In general, it is recommended to avoid concurrent flash operations from multiple software components and ensure that flash accesses are properly synchronized to prevent conflicts between OTA programming activities and any other flash users in the system. There’s no synchronization support between Fee/NvM and Mem_43_INFLS.
5. Yes, that’s correct flow. If fact, the only requirement is that there should be valid application in passive partition before the swap and signatures (or secure boot configuration in general) should be updated accordingly.
We have basic OTA demo “SW32K3_OTADEMO_0.8.0_D2203” for S32K344 - it shows how to write new application to passive block and then request AB SWAP (this is a feature of HSE firmware). RTD 1.0.0 is used in this demo. Next more advanced demo is “S32K396 OTA Demo version 0.4.0” which shows how to update firmware via ethernet. This one uses RTD 3.0.0 P07. Both demos can be found in S32K3 Reference Software: https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=SW32K3-REFSW-D Click on the link and then search for “Automotive SW - S32K3 - OTA Demo”. These are the only versions we have, it’s only reference software, it’s up to users to migrate it to other derivatives or to newer RTD packages if needed.
And we have following OTA trainings: https://www.nxp.com/design/design-center/training/TIP-CONNECTS2021-AUT428 https://www.nxp.com/design/design-center/training/TIP-NXP-AUT-T3955A
Both can be found in Training section on S32K3 page: https://www.nxp.com/products/S32K3
Also you can take a look at “S32K3XX HSE and OTA Advance Training [TR744101]” which can be downloaded from Documentation -> Secure files: https://www.nxp.com/products/S32K3
Regards, Lukas
View full article
