S32K中的主题 S32K Series Bootloader Application Jump Issue Across Different Custom Board Designs

S32K Series Bootloader Application Jump Issue Across Different Custom Board Designs

Joseph_David — Wed, 24 Sep 2025 06:08:33 GMT

Hello NXP Community,

I'm experiencing an issue with bootloader implementation across two custom S32K358 boards and would appreciate your insights.

**Setup:**
- Both boards use the same S32K358 microcontroller
- Board 1: Bootloader functions correctly - successful jump to application and firmware upgrade
- Board 2: Same bootloader project fails - unable to jump to user application

**Key Differences Between Boards:**
- UART communication pin assignments
- I2C communication pin assignments
- Other peripheral pin configurations
- Same microcontroller and core functionality

**Issue:**
The identical bootloader code that works perfectly on Board 1 , but fails to jump to the user application on Board 2, despite using the same S32K358 controller.

**Questions:**
1. Could peripheral pin configuration differences affect bootloader-to-application transitions?
2. Are there specific registers or initialization sequences that might be board-dependent?
3. What debugging approaches would you recommend for isolating this issue?

Has anyone encountered similar behavior with S32K358 bootloaders across different board designs? Any guidance on potential root causes or debugging strategies would be greatly appreciated.

Best regards,

M.J.David

Re: S32K Series Bootloader Application Jump Issue Across Different Custom Board Designs

PetrS — Thu, 25 Sep 2025 07:39:06 GMT

Hi,

1. Could pin configuration differences affect the transition?
Yes, indirectly. Differences that change clock source validity (FXOSC), assert PMIC/SBC resets, or trigger unexpected interrupts/NMIs can prevent the application from starting even though the branch happened.

2. Board‑dependent registers/sequences?
Yes: VTOR + vector table, watchdog (SWT), clocks/PLL run‑mode, TCM ECC init, cache/MPU state, and any SAF/HSE policies your build relies on. All of these must be consistent across bootloader and application for a clean jump.

3. Debugging approach to isolate root cause?
- Prove the app runs standalone on Board 2.
- Verify linker/vectors; set VTOR/MSP correctly; add early fault logging.
- Disable watchdog, caches, MPU; return peripherals to POR state; then jump.
- Attach a debugger after the jump to inspect SCB/stack/PC/fault regs.
Below are some guides how to find hardfault cause...
https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Handling-Interrupt-DS3-5-RTD300/ta-p/1806259
https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Interrupt-Handling-using-a-script-DS3/ta-p/1818507

BR, Petr