S32K3 bootloader and HSE - best practice ?

[coratron]

Hi NXP team,

We are implementing a robust OTA update architecture on an S32K312 using HSE full-block A/B swap.

Our target architecture is:

- S32K312 with 2 MB PFlash split into two 1 MB physical blocks.
- HSE AB_SWAP is used via the passive-block activation service.
- OTA package is received over Modbus/serial.
- Bootloader stages the signed image into the passive PFlash block.
- HSE verifies the passive image/SMR.
- Bootloader requests AP_SWAP.
- After reset, the newly swapped bank boots provisionally.
- A confirm command makes the swap permanent; otherwise the device rolls back.

Originally we tried to keep one global bootloader in DFlash, outside the two PFlash banks. That bootloader would receive OTA, program the passive PFlash bank, request HSE AP_SWAP, and then continue to manage confirm/rollback.

We ran into architectural and runtime complexity with that approach:

1. HSE AB_SWAP appears to operate on full PFlash block boundaries, not arbitrary app partitions.
2. A single DFlash bootloader is outside the swapped/authenticated bank image.
3. The active PFlash bank still needs valid boot/IVT/reset structure after swap.
4. We had difficult execution hazards when DFlash was also involved in bootloader runtime/record handling.
5. It became unclear whether a global DFlash bootloader is compatible with a clean full-bank HSE AB_SWAP production design.

We therefore moved to a duplicated PFlash bootloader mode for now:

- Each 1 MB PFlash bank contains its own IVT + bootloader + application.
- The bootloader has a reserved slot at the base of each bank.
- The application starts after the bootloader slot.
- The signed OTA image is a full bank image containing bootloader + application.
- After HSE AB_SWAP, the newly active bank is self-contained and bootable.

This appears much cleaner for HSE full-block A/B swap, but I would like to confirm the intended/production-safe approach. This is suboptimal as it partially defeats the purpose of a factory bootloader.

Questions:

1. For S32K312 HSE AB_SWAP, is a single global DFlash-resident bootloader outside the swapped PFlash banks a supported/recommended architecture?
2. Or does HSE AB_SWAP effectively require/recommend that each swapped PFlash block be independently bootable, with its own IVT/bootloader/reset path?
3. If a DFlash bootloader is possible, how should the post-swap boot flow be structured so SBAF/HSE boot expectations are still met?
4. Are there any NXP reference examples showing a DFlash bootloader managing full-block HSE AB_SWAP on S32K3?
5. For production OTA with rollback/confirm semantics, is the duplicated PFlash bootloader model the safer intended design?

We have seen that code and IVT can be linked into DFlash by modifying the linker script (and we tried that), but our question is specifically about whether that is appropriate when using HSE full-block A/B swap and secure boot/SMR verification.

Thank you.

[coratron]

Thanks for your prompt reply @lukaszadrapa . That clarifies and helps substantially - we have been able to re-evaluate our bootloader implementation in DFlash and were successful.

The team is used to the documentation / accessibility from other vendors and finds NXP to be surprisingly confusing compared to them despite being a leader in automotive applications.

Your prompt feedback makes up for these gaps, so thanks again for your help - much appreciated. I will mark your reply as the solution, with the following feedback directed at your team:

- A Dflash bootloader + HSE demo would have been great to save time (yours included). I am sure this is the natural setup for people that use AB_SWAP.

- NXP should unify and get the documentation and software stack organised (long term) - compatibility / versions are scattered, there is no one source of information which leads to confusion.

Regards 

[lukaszadrapa · Accepted solution]

Hi @coratron 

1. For S32K312 HSE AB_SWAP, is a single global DFlash-resident bootloader outside the swapped PFlash banks a supported/recommended architecture?

There are no limitations from HW point of view. Both options are possible. If the size of data flash is sufficient and you do not plan to use it for your data, the bootloader can be placed in the data flash. If you need data flash for other purposes then having two copies of the bootloader in both partitions is common practice.

2. Or does HSE AB_SWAP effectively require/recommend that each swapped PFlash block be independently bootable, with its own IVT/bootloader/reset path?

No, there’s no such requirement. It is sufficient to have valid IVT only in data flash (bootloader’s IVT). Common practice is that bootloader is always started after reset and then then the bootloader jumps to user application.

3. If a DFlash bootloader is possible, how should the post-swap boot flow be structured so SBAF/HSE boot expectations are still met?

There are no specific requirements coming from SBAF or HSE. Once bootloader is started, it can decide if it should jump to application or if it should download new application or if it should do rollback, etc. and then it should reset the device (in case of rollback/swap) or jump to the application.

4. Are there any NXP reference examples showing a DFlash bootloader managing full-block HSE AB_SWAP on S32K3?

We don’t have such example.

5. For production OTA with rollback/confirm semantics, is the duplicated PFlash bootloader model the safer intended design?

I would not classify either approach as universally safer. The suitability of a particular architecture depends on the overall system design, security requirements, OTA workflow and rollback strategy. Both concepts can be implemented in a robust production solution.

Regards,
Lukas