I am working with the NXP S32K344 Secure Boot example using SHE standard (HSE), and have encountered an issue where, after updating the firmware and following the proper SMR/CMAC update procedure, the application does not jump to the user code after reset. All status responses from the HSE API are OK, but the boot does not proceed as expected.
## Debug Information
Board: S32K3X4EVB-T172
Example Project: S32K344_Hse_SHE_SecureBoot_Example
1. Original (Working) Binary Properties
- File name: `S32K344_SecureBoot_AppBL.bin`
- Size: **4096bytes** (4 KB)
- Secure Boot passes and jumps to user code.
2. After Firmware Change (Increased Delay in Code)
- File name: Same as above.
- Size: **4096 bytes** (no change)
- Changed only a delay in the firmware.
3. Secure Boot/CMAC/SMR Steps Followed
- Generated new CMAC with `AesCmacGenerate` over the correct region (4096 bytes).
- Installed new SMR entry with `HSE_InstallSmrEntry` (received `HSE_SRV_RSP_OK`).
- Installed new Core Reset entry with `HSE_InstallCoreResetEntry` (received `HSE_SRV_RSP_OK`).
- All APIs return `HSE_SRV_RSP_OK`.
- After reset, **boot does not jump to application**.
4. Code/Configuration Details
- In `main.c` and SMR config, binary length (`smrSize`, `codeLength`, CMAC region) set to **4096** bytes (matches actual file size).
- App boot header uses `.codeLength = 4096`.
- No error responses from any HSE calls.
- Keys and catalog setup as per NXP example.
Why does Secure Boot not jump to the application after a minor firmware change, even though all SMR/CMAC updates and responses are OK?
Is there a known issue with the NXP example flow, or is there an undocumented step required (e.g., flash erasure, header field, alignment)?
Steps to Reproduce
1. Build and flash working example; Secure Boot passes.
2. Make a small code change (increase delay), rebuild. Binary size remains 4096 bytes.
3. Regenerate CMAC over new binary, update SMR entry, update Core Reset entry.
4. Flash new binary.
5. On reset, app does not start, even though all API calls return OK.
