S32K MCU reset when using FLASH commands.

[gberthiaume]

Context:

I'm building a bootloader for the s32k144 MCU using the AN12218 as a reference. I'm using the processor expert flash_driver to program internal flash memory.

The problem:
When using the FLASH_DRV_CommandSequence() function, the MCU reset completely; as you can see here:

When looking at the system reset status register, the reset seems to be caused by a LOCKUP EVENT.

The question

What can cause such behaviour?
Can I catch this event to better understand where it comes from? 

This function happens to be located inside the RAM because of the START_FUNCTION_DEFINITION_RAMSECTION macro. Do I need to do something to ensure it works properly?

Additional information

• My bootloader linker file:

• I'm trying to write my program to 0x0000B000 and above.
• The problem is still happening without debugger.
• The processor expert component
  

Your help is very much appreciated.

[danielmartynek]

Hello gberthiaume@nordresa.com,

Just to be sure, I would read the program counter in the CommandSequence function to see if it is in RAM, disable interrupts and make sure no Flash data are read during the flash operation.

Cortex-M4 Devices Generic User Guide | Lockup – Arm Developer 

You can catch the event, please create a HardFault handler and debug the exception.

Fault handling on S32K144 

Could you share the project? If you don't want to post it here, you can create a ticket:

How to submit a new question for NXP Support  

Regards,

Daniel 

[gberthiaume]

Hi danielmartynek‌.

I fixed the problem by disabling the Global IRQ before writing to the flash.

    INT_SYS_DisableIRQGlobal();

    sdkStatus = FLASH_DRV_EraseSector(&g_flashSSDConfig, memoryAddress, FEATURE_FLS_PF_BLOCK_SECTOR_SIZE);

    INT_SYS_EnableIRQGlobal();

While the program now behaves as expected, this solution seems like a hack... 

Could you explain to me how the interrupt could cause this problem? 

To my understanding, the only interrupt that could fire while the program is writing to the flash is the systick. 
I also have the UART interrupt enable, but it shouldn't fire between write. 

[gberthiaume]

Any update on this danielmartynek? 
Disabling interrupts before writing to flash seems to be an SDK problem. 

What do you think? 

[danielmartynek]

Hello Gabriel,

I'm sorry, I must have forgotten to reply.

There is only one PFlash block (or partition) on S32K144.

And when the FTFC module is programing the block, the core must not access the block.

If the SysTick is causing this failure, it is because you have either the Systick handler in PFlash or the Interrupt vector table is in PFlash or both.

The SDK driver does not have to disable interrupts, this is application-dependent.

Regards,

Daniel  

[gberthiaume]

If the SysTick is causing this failure, it is because you have either the Systick handler in PFlash or the Interrupt vector table is in PFlash or both.

I think you're are right.
By looking at my configuration, I can see my P-Flash goes from 0x0 to 0x80000.

My liker file is configured to put the bootloader in the range of the P-flash.

This configuration is explained in the AN12218 (S32K1xx Bootloader) application note, but there's is no mention of the issue. Do you recommend another alternative for the memory management of a bootloader? 

Thanks for your reply.

Regards,

Gabriel

[danielmartynek]

Hello Gabriel,

I assume that in your SDK application, the vector table is SRAM.

Please see the linker file and the startup code.

S32K1xx_flash.ld

So fetching the interrupt vector should not compose a problem.

Please find the address of the SysTick_Handler function in the .map file (Debug_FLASH folder).

I guess it is in PFlash block and thus calling this function during a PFlash operation causes a collision on the block.

Regards,

Daniel

[gberthiaume]

The systick_handler is located at 0x4d14

Wich is in the P-Flash (Exactly as you said)

I assume that in your SDK application, the vector table is SRAM.

Therefore, I conclude that the vector table is not in SRAM.

I suppose this is why, in the AN12323 app note, the bootloader is put in the FlexMemory:

The bootloader memory map:

If the SysTick is causing this failure, it is because you have either the Systick handler in PFlash or the Interrupt vector table is in PFlash or both.

But, in the AppNote example, the Interrupt Vector is still in the PFlash:

Why is this not a problem? 
Thanks.

ps.

I don't want to use too much of your time, so if you have a good reading on microcontroller memory fundamentals, please let me know.

Gabriel

[danielmartynek]

Hi Gabriel,

I'm not aware of any document that would address all of this.

The interrupt vector table (initial SP value, reset vector) has to be at 0x00000000, because out of the system reset the execution starts at this address (VTOR = 0x00000000).

I just tested the S32K144_FOTA_Bootloader SW (AN12323).

The startup.c file copies the vector table in SRAM before the application enables interrupts.

Also, the interrupt handlers are in DFlash as you mentioned:

Regards,

Daniel