S32K MCU reset when using FLASH commands.

cancel
Showing results for 
Search instead for 
Did you mean: 

S32K MCU reset when using FLASH commands.

1,310 Views
gberthiaume
Contributor III

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:

pastedImage_1.gif

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

pastedImage_4.png

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:

pastedImage_5.png

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


Your help is very much appreciated.

Labels (1)
8 Replies

836 Views
danielmartynek
NXP TechSupport
NXP TechSupport

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 

pastedImage_5.png

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 

0 Kudos

836 Views
gberthiaume
Contributor III

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. 

0 Kudos

836 Views
gberthiaume
Contributor III

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

What do you think? 

0 Kudos

836 Views
danielmartynek
NXP TechSupport
NXP TechSupport

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  

836 Views
gberthiaume
Contributor III

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.
pastedImage_1.png

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


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

0 Kudos

836 Views
danielmartynek
NXP TechSupport
NXP TechSupport

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

pastedImage_1.png

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

0 Kudos

836 Views
gberthiaume
Contributor III

The systick_handler is located at 0x4d14

pastedImage_1.png

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

pastedImage_2.png

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:

pastedImage_4.png

The bootloader memory map:

pastedImage_5.png

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:

pastedImage_7.png

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

0 Kudos

836 Views
danielmartynek
NXP TechSupport
NXP TechSupport

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.

pastedImage_3.png

pastedImage_4.png

pastedImage_5.png

pastedImage_6.png

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

pastedImage_7.png

Regards,

Daniel

0 Kudos