Intermittent Bootloader → Application Jump Failure on S32K3 (Not Reproducible on All Boards)

[yusupkhan241]

Hi NXP Team,

I’m continuing from the earlier discussion on C40 flash erase/program limitations C40 Flash Erase/Write from Bootloader in S32K311 (Same Flash Block Execution)  in S32K3 devices:

With your support, we resolved the flash erase/program issue by:

• Ensuring no execution from the target flash block during operations

Current Issue

We are now observing an intermittent issue during bootloader → application jump.

• The same jump implementation works reliably in most cases:
• Tested on ~20 boards
• Application reflashed >100 times
• ECU reset >1000 times
• No issue observed in these scenarios
• However, in 2 boards, we occasionally see:
• Control does not jump to application
• Device remains stuck in bootloader
• Recovery method:
• Reflashing a combined HEX (bootloader + application) using debugger resolves the issue
• Concern:
• In production (vehicle-installed ECU), reflashing via debugger is not practical

Jump Implementation Used

C

void JumpToApplication(void)

{

    uint32 appStack = *(uint32 *)(APP_STARTADDR);

    uint32 func = *(uint32 volatile *)(APP_STARTADDR + 0xC);

    func = *(uint32 volatile *)(((uint32)func) + 0x4);

    DisableAllInterrupts();

    S32_SCB->VTOR = APP_STARTADDR;

    __asm volatile ("msr msp, %0" :: "r"(appStack));

    __asm volatile ("msr psp, %0" :: "r"(appStack));

    func = ((((uint32)func) & 0xFFFFFFFEU) | 1U);

    (*(void (*)(void))func)();

    while (1);

}

static void DisableAllInterrupts(void)

{

    for (int i = DMATCD0_IRQn; i <= SoC_IRQn; i++)

    {

        IntCtrl_Ip_DisableIrq((IRQn_Type)i);

        IntCtrl_Ip_ClearPending((IRQn_Type)i);

    }

    S32_SysTick->CSRr = 0U;

}

Observations

• Issue is not consistently reproducible
• Appears intermittent & happens randomly.
• Full image reflash (combined HEX) restores normal behaviour

Request for Guidance

Could you please help with:

1. What additional checks should be added before jumping to application?
2. Are there any known corner cases (MPU, cache, VTOR, barriers, etc.) that could cause this intermittent behaviour?
3. Could this be related to:
• Cache state (I/D cache not cleaned/disabled)?
• Incomplete flash programming or alignment issue?
• Vector table or reset handler inconsistency?
4. Any recommended production-grade sequence before jump (barriers, cache handling, etc.)?

If any additional details are needed, please let me know and thanks in advance for your support.

Best regards,
Yusup Khan

S32DS-ARM S32K3 S32K31XEVB-Q100  @danielmartynek C40 Flash Erase/Write from Bootloader in S32K311 (Same Flash Block Execution) 

[danielmartynek]

Hi Yusup,

What does it mean that the device remains stuck in the bootloader?
Can you attach a debugger and check where it is stuck?
Is it a fault exception or a software loop?

Is reflashing really necessary, or would a POR be sufficient?

Regarding MPU and cache, it is good practice to clean and disable the cache. The application reconfigures the MPU for its use case, so the cache should be cleaned and disabled anyway.

You can add memory barriers or refer to the S32K3xx Reference Manual, Section 3.8 “Serialization of Memory Operations” and use the read-after-write sequence.

Also, check the DCM_GPR registers for faults. (RM, Table 231. DCM controlled features and availability in product family.)

Make sure that the clock configuration matched one of the clock options listed in the RM, e.g. Table 157. Option A - High Performance mode (CORE_CLK @ 160 MHz).

Anyway. the key point is to identify the loop where the bootloader is stuck. If there is a fault exception, you need to gather more information about the fault.

https://community.nxp.com/t5/S32K-Knowledge-Base/Example-S32K312-HARDFAULT-Handling-Interrupt-DS3-5-...

https://community.nxp.com/t5/S32K-Knowledge-Base/How-To-Debug-A-Fault-Exception-On-ARM-Cortex-M-V7M-...

https://community.nxp.com/t5/S32K-Knowledge-Base/Fault-handling-on-S32K14x/ta-p/1114447

Regards,

Daniel

[yusupkhan241]

Hi  @danielmartynek 

Thanks for your response.

To clarify, we are observing two intermittent behaviours:

1) Bootloader active but jump fails:

- Bootloader receives update command and successfully programs the application.

- Application CRC check passes.

- However, after issuing jump, control does not transfer to the application.

2) Bootloader becomes unresponsive:

- No UART response and no LED indication.

- POR/software reset does not recover.

- Only reflashing via debugger restores the system.

So far, POR alone does NOT resolve the issue.

For the jump sequence, we are currently using the following approach:

- Validate application before jump:

•             IVT marker check
•             Stack pointer (not 0x0 / 0xFFFFFFFF)
•             Reset handler validity

- Jump sequence includes:

•             Disable interrupts (clearing individually)
•             Disable SysTick
•             Cache clean + invalidate
•             VTOR update
•             MSP/PSP update
•             DSB/ISB barriers
•             Jump to reset handler

/* -------------------------------------------------------------------------- */
/* Flash memory layout */
/* -------------------------------------------------------------------------- */
/** @brief Base address of internal flash memory. */
#define FLASH_BASE_ADDR (0x00400000U)
/** @brief Total flash memory size (1 MB). */
#define FLASH_TOTAL_SIZE (0x00100000U)
/** @brief End address of internal flash memory. */
#define FLASH_END_ADDR (FLASH_BASE_ADDR + FLASH_TOTAL_SIZE)
/** @brief Start address of the application image region. */
#define APP_STARTADDR (0x00422000U)
/** @brief Maximum supported application image size in bytes. */
#define APPLICATION_IMAGE_SIZE (FLASH_END_ADDR - APP_STARTADDR)
/** @brief Maximum payload buffer allocated per transfer step. */
#define FLASH_CHUNK_SIZE (512U)
/** @brief Chunk size used during post-reset CRC verification. */
#define CRC_CHUNK_SIZE (4096U)

/** @brief Expected IVT marker value at the application image base. */
#define IVT_MARKER_MAGIC (0x5AA55AA5U)
/** @brief Kept for layout compatibility with existing application image builds. */
#define IVT_ENTRY_ADDR (APP_STARTADDR + 0x2000U)

/* -------------------------------------------------------------------------- */
/* Application Jump Configuration */
/* -------------------------------------------------------------------------- */
/** @brief Offset to core entry address from application start. */
#define FLASH_APP_CORE_ENTRY_OFFSET (0x0CU)
/** @brief Offset to reset handler from core entry address. */
#define FLASH_APP_RESET_HANDLER_OFFSET (0x04U)
/** @brief Expected IVT marker magic value for valid application image. */
#define FLASH_IVT_MARKER_MAGIC (0x5AA55AA5U)

/** @brief Default erased 32-bit flash value. */
#define FLASH_ERASED_U32_VALUE (0xFFFFFFFFU)
/** @brief Default zero 32-bit value. */
#define FLASH_ZERO_U32_VALUE (0x00000000U)

/**
* @brief Validate an address read from application flash.
*
* @details
* This function checks whether a given address value is valid and usable.
* It filters out common invalid values such as:
* - 0x00000000 (unprogrammed / null)
* - 0xFFFFFFFF (erased flash)
*
* This function is used for validating stack pointer and reset handler.
*
* @param addressValue Address read from flash (stack pointer or reset handler).
*
* @return TRUE if the value is valid, otherwise FALSE.
*/
static boolean Flash_IsAddressValid(uint32 addressValue)
{
return ((addressValue != FLASH_ZERO_U32_VALUE) &&
(addressValue != FLASH_ERASED_U32_VALUE)) ? TRUE : FALSE;
}

static AppJumpError_t Flash_PrecheckApplication(void)
{
uint32 appStack;
uint32 coreEntry;
uint32 resetHandler;

/* IVT marker validation */
if ((*(volatile const uint32 *)APP_STARTADDR) != FLASH_IVT_MARKER_MAGIC)
{
return APP_JUMP_ERR_CORRUPT;
}

/* Stack pointer validation */
appStack = *(volatile const uint32 *)APP_STARTADDR;

if (Flash_IsAddressValid(appStack) == FALSE)
{
return APP_JUMP_ERR_STACKPTR;
}

/* Reset handler validation */
coreEntry = *(volatile const uint32 *)(APP_STARTADDR + FLASH_APP_CORE_ENTRY_OFFSET);
resetHandler = *(volatile const uint32 *)(coreEntry + FLASH_APP_RESET_HANDLER_OFFSET);

if (Flash_IsAddressValid(resetHandler) == FALSE)
{
return APP_JUMP_ERR_RESETHANDLER;
}

return APP_JUMP_OK;
}

/**
* @brief Transfer execution from bootloader to application.
*
* @details
* This function performs the final steps required to transfer control
* from the bootloader to the application firmware:
*
* - Disables all interrupts
* - Stops system tick
* - Clears and invalidates caches
* - Sets the Main Stack Pointer (MSP)
* - Updates vector table
* - Jumps to application reset handler
*
* IMPORTANT:
* - All validation must be completed before calling this function.
* - This function does not return.
*/
void JumpToApplication(void)
{
uint32 appStack;
uint32 coreEntry;
uint32 resetHandler;

/* ------------------------------------------------------------------ */
/* Read application vector table */
/* ------------------------------------------------------------------ */
appStack = *(volatile const uint32 *)(APP_STARTADDR);
coreEntry = *(volatile const uint32 *)(APP_STARTADDR + FLASH_APP_CORE_ENTRY_OFFSET);
resetHandler = *(volatile const uint32 *)(coreEntry + FLASH_APP_RESET_HANDLER_OFFSET);

/* ------------------------------------------------------------------ */
/* Disable interrupts */
/* ------------------------------------------------------------------ */
Flash_DisableAllInterrupts();

/* Disable SysTick */
S32_SysTick->CSRr = 0x00000000;

/* ------------------------------------------------------------------ */
/* Cache handling */
/* ------------------------------------------------------------------ */
Cache_Ip_Clean(CACHE_IP_CORE, CACHE_IP_DATA, TRUE);
Cache_Ip_Invalidate(CACHE_IP_CORE, CACHE_IP_INSTRUCTION);

/* ------------------------------------------------------------------ */
/* Set vector table address */
/* ------------------------------------------------------------------ */
S32_SCB->VTOR = (uint32)APP_STARTADDR;

/* ------------------------------------------------------------------ */
/* Set Main Stack Pointer */
/* ------------------------------------------------------------------ */
__asm volatile ("msr msp, %0" :: "r"(appStack));
__asm volatile ("msr psp, %0" :: "r"(appStack));

__asm__ __volatile__ ("dsb 0xF" : : : "memory");
__asm__ __volatile__ ("isb 0xF" : : : "memory");

/* Ensure Thumb mode */
resetHandler = (resetHandler & FLASH_THUMB_ADDRESS_MASK) | FLASH_THUMB_ADDRESS_BIT;

/* ------------------------------------------------------------------ */
/* Jump to application */
/* ------------------------------------------------------------------ */
((void (*)(void))resetHandler)();

/* Should never reach here */
while (1)
{
/* Trap */
}
}

We have a few specific questions:

1) Is there anything critical missing or incorrect in this validation/jump sequence?

2) Do you recommend additional checks (e.g., stricter SP/PC range validation or alignment checks)?

3) Could cache/MPU state or missing barriers still cause this intermittent behaviour even with this sequence?

4) Is there any known dependency on flash alignment or ECC correction that could explain why debugger reflashing always resolves the issue?

5) Additionally, we observed that using global interrupt disable:

    __asm volatile("cpsid i");

causes the jump to fail, whereas disabling interrupts one-by-one works reliably:

    for (irqIndex = DMATCD0_IRQn; irqIndex <= SoC_IRQn; irqIndex++)

    {

        IntCtrl_Ip_DisableIrq((IRQn_Type)irqIndex);

        IntCtrl_Ip_ClearPending((IRQn_Type)irqIndex);

    }

Could you please advise why global interrupt disable might affect the jump behaviour in this case?

S32DS-ARM S32K3 

Best regards,

Yusup

[danielmartynek]

Hi @yusupkhan241,

You tested it on many boards successfully, and only a few show this issue. So this is clearly sporadic, and I cannot determine the root cause from the available information. There are many possible causes, and proper debugging on a failing board (with a debugger attached) is required.

What is interesting is that a power-on reset does not help. If this were just a runtime issue (e.g. bad cache state, pending IRQ, CPU register state, or leftover RAM content), a POR should clear it.
Do the other working boards behave normally standalone after a POR?
If yes, this points to something related to non-volatile memory. I would recommend dumping the flash content on a failing board and comparing it byte-for-byte with a working one.

Regards,

Daniel