C40 Flash Erase/Write from Bootloader in S32K311 (Same Flash Block Execution)

[yusupkhan241]

Hi NXP Support Team,

I am currently working on a bootloader implementation for the S32K311 device and need clarification regarding C40 flash erase/program behavior when operating within the same flash array.

Context:

• MCU: S32K311
• Flash Size: 1 MB
• Bootloader region: ~128 KB (starting at 0x00400000)
• Application region: remaining flash (~896 KB)
• Both bootloader and application reside within the same flash array/block

Observed Behavior:
While attempting to erase/program the application region from the bootloader, the C40 driver returns an error and execution goes into the error handler. This appears consistent with the known limitation of not being able to perform flash operations while executing from the same flash array.

Concern / Confusion:
I reviewed the “Unified Bootloader” example provided by NXP. From initial analysis, it appears that the flash driver (C40_Ip) functions are linked and executed from flash memory itself.

This raises the following questions:

1. How does the Unified Bootloader example successfully perform flash erase/program operations if the code is executing from flash?
2. Are the flash driver routines internally relocated to RAM (e.g., via linker sections or runtime copying), even if not explicitly visible?
3. Is there any implicit mechanism (e.g., SDK/RTD configuration, compiler/linker behavior) that ensures flash operations are executed from RAM?
4. For single-block devices like S32K311, is executing flash erase/program strictly required to be done from RAM?
5. Could you confirm the recommended approach for:
• Erasing/programming application flash from bootloader
• Handling this in production-grade implementations

Additional Notes:

• I ensured that erase operations are sector-aligned.
• Write operations follow alignment constraints.
• The issue persists unless execution is moved to RAM.

It would be helpful if you could clarify how the reference example handles this internally and provide guidance on the correct implementation approach.

Thank you for your support.

Best regards,
Yusup Khan  S32DS-ARM #S32K344-WB

[yusupkhan241]

@danielmartynek 

This issue is currently blocking further progress on our side. Could you please help with the next steps or suggest additional areas we should investigate? Also, let me know if you need any logs, traces, or specific test scenarios—I can share them promptly.

Appreciate your support on this.

Thanks,
Yusup

[danielmartynek · Accepted solution]

Hello Yusup,

I tested the S32K344 project today.

It did not pass the Mem_43_INFLS_Erase() function because of this error:

This was resolved by adding this batch:

After that it ended up in a fault exception that was resolved by enabling this option:

Please test it on your side.

Thank you,

BR, Daniel

[yusupkhan241]

Hi @danielmartynek 

Thank you for the support. The issue is resolved now and the erase operation is working as expected.

I have a few follow-up questions regarding cache usage on S32K3:

1. Is there any way to perform flash erase and write operations without using the cache module? Or is cache handling mandatory for reliable operation on this platform?
2. If cache must be used, what precautions should be taken while performing flash operations (erase/write)?
• Are there specific steps required before and after flash operations (e.g., cache clean/invalidate)?
• Any recommended sequence from NXP?
3. Also, could you please share the pros and cons of enabling cache in such use cases?

Additionally, I have a bootloader and application setup, and I am using the following API to jump from bootloader to application. If cache cannot be excluded, I would like to confirm whether my jump implementation is correct or if any cache-related handling needs to be added.

void JumpToApplication(void)

{

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

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

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

    /* Disable all interrupts */

    DisableAllInterrupts();

    /* Set application's vector table using SCB register */

    S32_SCB->VTOR = APP_STARTADDR;

    /* Set MSP & PSP */

    __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;

}

Please let me know if any additional steps (especially related to cache, MPU, or barriers) are required before jumping to the application.

Thanks,

Yusup

[danielmartynek]

HI @yusupkhan241,

Great to hear the issue has been resolved.

Can you please place the cache questions into a new thread?

Thank you

[yusupkhan241]

Hi @danielmartynek 

Yes, I have created a new thread for the cache-related questions. 

https://community.nxp.com/t5/S32K/S32K3-Cortex-M7-Cache-Handling-Requirements-for-Flash-Operations/m...

Thank you for the support. S32K3

Best regards,
Yusup

[danielmartynek]

Hello Yusup,

Sorry for the delay—I was out of the office for a few days.
I will need to reproduce the issue on my side tomorrow once I’m back.
I see that you have already shared an S32K344 test project, which I can use for validation.
If you also have a minimal S32K311 project that reproduces the same behavior, please share it as well, if you don't want to share it here, please create a support ticket.

Regards,

Daniel

[danielmartynek]

Hi @yusupkhan241,

1 & 2.
The Unified Bootloader is an unofficial NXP demo that has only been published on the community forum, and therefore it is not supported by NXP technical support.
However, I can see that this demo has been ported to the S32K312, S32K314, S32K324, and S32K344 devices, all of which contain two or more PFlash blocks.

3 & 5.

3 & 5.
If you are using the C40_Ip driver, you must relocate the flash APIs to SRAM. Please refer to the following example that demonstrates the required setup:
https://community.nxp.com/t5/S32K-Knowledge-Base/S32K312-C40-Ip-SRAM-RTD-500-DS35/ta-p/2074245

Or you can use the INFLS MCAL driver instaed, which automatically relocates the flash routines to SRAM when this option is enabled. This is the recommended approach.

4.

There are two PFlash blocks and one DFlash on S32K311. So it is not a must.

Regards,

Daniel

[yusupkhan241]

Hi Daniel (@danielmartynek) ,

Thank you for the response. I have enabled the INFLS MCAL driver with SRAM relocation (Mem Load Access Code On Job Start enabled). However, I still observe the following:

1. Flash operations succeed in Block 2 but fail with E_NOT_OK in Block 0 when the application is executing from Block 0.
2. It appears that even though INFLS relocates flash routines to SRAM, the application code (and possibly vector table/interrupts) still executes from Block 0, causing failure during erase.
3. Could you confirm whether it is mandatory that no code (including interrupts/vector table) executes from the target flash block during erase/program, even when using INFLS?
4. What is the recommended approach to erase/program Block 0 in such cases—should the entire application be executed from RAM or relocated to another flash block?

Test Cases:

1. Using Block 2 (0x00600000 – C40_CODE_ARRAY_0_BLOCK_2_S256):
   • Erase & program operations → SUCCESS
2. Using Block 0 (0x00480000 – C40_CODE_ARRAY_0_BLOCK_0_S064):
   • Erase operation → Returns E_NOT_OK

Thanks,
Yusup

[danielmartynek]

Hello Yusup,

Your observation is correct.
The flash block being programmed or erased must not be accessed during the operation. This limitation applies not only to the vector table and the interrupt service routines (ISRs), but also to any constants or data located in flash that the ISRs may read.
To isolate the root cause, try globally masking interrupts before launching the flash operation. This will help verify whether the issue originates from an interrupt activity rather than from INFLS itself.

Regards,

Daniel

[yusupkhan241]

Hi @danielmartynek ,

Thank you for the clarification.

I tried masking global interrupts before initiating the flash operation, but the issue still persists. The erase operation in Block 0 continues to return E_NOT_OK.

Please let me know if you need any additional details, logs, or specific test scenarios from my side. I can share further information or perform any checks required to help isolate the issue.

Thanks,
Yusup

[yusupkhan241]

S32K3 S32K31XEVB-Q100 S32DS-ARM