RT0152 proper flow for resetting check after updating FLASH (XIP)

cancel
Showing results for 
Search instead for 
Did you mean: 

RT0152 proper flow for resetting check after updating FLASH (XIP)

Jump to solution
460 Views
variable_andrew
Senior Contributor I

After loading a new binary (XIP program) onto FLASH on the RT1052, i try to reset the device in code as follows:

    // we're good to go - restart RT1052
    NVIC_SystemReset();
    SRC_DoSoftwareResetARMCore0(SRC);
    while (1){
    	//shutdown/restart
    }

 

but this doesn't guarantee a restart of the device - sometimes i have to reset power to trigger a proper reset.

 

What's the proper way to force a reset from software?

Labels (1)
Tags (1)
0 Kudos
1 Solution
219 Views
variable_andrew
Senior Contributor I

So the end solution for me is an recurring theme I'm having with all the FLASH related SDK code and caching - and the compiler not allocating critical code to internal RAM (appropriately?).

So NVIC_SystemReset, taskDISABLE_INTERRUPTS, vTaskSuspendAll, __disable_irq are all allocated to FLASH.

That means after I update flash and the ^^^ code bits get overwritten, if I try to call any of those functions - who knows what will happen.

So by copying those functions to my own code, and forcing them to be in RAM, I'm able to reset appropriately.

I have similar issues when setting up FLASH  / caching / etc - I have to change a fair bit of SDK code to force inline (instead of just inline) - or change the functions with __RAMFUNC(RAM)

 

So end result is that I'm able to reset now after DFU, but curious as to if there's any plan or flag to be intended to move such functions to RAM?

View solution in original post

0 Kudos
9 Replies
446 Views
jeremyzhou
NXP TechSupport
NXP TechSupport

Hi, 

Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
On my side, the NVIC_SystemReset() is able to trigger the reset event, so I think your code is able to make it too, doesn't it work?
If not, whether you can introduce the steps of replicating the phenomenon, then I will give some tests to confirming.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
435 Views
variable_andrew
Senior Contributor I

Hi @jeremyzhou ,

Right, when I do the code snippet listed in the original post, it doesn't trigger a reset always.

The hints to reproduce it that I have are:

I am running using XIP mode

If i don't change any code in FLASH (so I simply overwrite the contents of FLASH with the same contents), then the original post reset method works 100% of the time.

If i change FLASH contents significantly, and then execute the reset mechanism, sometimes reset appears to fail.

If I hard reset with new code - the new code works just fine, so it seems the FLASH copy works just fine...

The code that's executing reset is in a function allocated to RAM:

__RAMFUNC(RAM) static void firmware_update(){
  //we have all the data - jump to a RAM func and copy it to FLASH start, reset
  taskDISABLE_INTERRUPTS();
  vTaskSuspendAll();
  __disable_irq();
  delay_ms(25);  //code in RAM... just trying to be extra safe here...
  int retries = 15;
  do{
    status = flash_copy_62000000_to_60000000();
  }while ((status != kStatus_Success) && (retries > 0));
  if (status == kStatus_Success){
    // we're good to go - restart RT1052
    NVIC_SystemReset();
    SRC_DoSoftwareResetARMCore0(SRC);
    while (1){
    	//shutdown/restart
    }
  }
  delay_ms(25);
  __enable_irq();
  xTaskResumeAll();
  taskENABLE_INTERRUPTS();
  //SHOULD never get here.... 
  if (retries == 0){
    assert(0);
  }
}

 

I believe my copy flash code is reliably safe...

 

 

 

 

 

If you'd like to reference the flash copy code, it's pretty straight forward, based on the MCUXpresso FLASH demo, here's the main stuff in a gist: https://gist.github.com/andrewrt/c94499159a41e9de918be266423b98b6

 

0 Kudos
407 Views
jeremyzhou
NXP TechSupport
NXP TechSupport

Hi,

Thanks for your reply.
What's around the percent of reset fails? And whether you try to run the code in either ITCM or DTCM for testing.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

0 Kudos
274 Views
variable_andrew
Senior Contributor I

Sorry for the delay @jeremyzhou ,

 

For failure %:

When the application (binary) is significantly changed, it seems to fail 100% of the time, so I have to POR the device.

When the application is not changed, it works 100% of the time.

 

If, I change from NVIC_RESET to the following (adding in the suggested FlexRAM reset from @mjbcswitzerland (I think I got it right in there?):

  //sanity check:
  taskDISABLE_INTERRUPTS();
  vTaskSuspendAll();
  __disable_irq();
  //	NVIC_SystemReset(); (static inline not working? copy source over:
  __ASM volatile ("dsb 0xF":::"memory");;                                                          /* Ensure all outstanding memory accesses included
                                                                        buffered write are completed before reset */
   SCB->AIRCR  = (uint32_t)((0x5FAUL << SCB_AIRCR_VECTKEY_Pos)    |
                            (SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |
                             SCB_AIRCR_SYSRESETREQ_Msk    );         /* Keep priority group unchanged */


 IOMUXC_GPR->GPR16 = IOMUXC_GPR_GPR16_FLEXRAM_BANK_CFG_SEL_MASK | IOMUXC_GPR_GPR16_INIT_DTCM_EN_MASK | IOMUXC_GPR_GPR16_INIT_DTCM_EN_MASK;

   __ASM volatile ("dsb 0xF":::"memory");;                                                             /* Ensure completion of memory access */

 

then it seems the RT1052 tries to reset, but fails to start back up... and I have to POR the device to get it running again (same as the above case where binary is changed.

0 Kudos
263 Views
jeremyzhou
NXP TechSupport
NXP TechSupport

Hi,
It makes me a bit confused, according to your description, it seems that you have two application demos and they both have the trigger reset function code. However, one works, and another fails, isn't right?
If yes, I think you need to confirm the trigger reset function whether being definitely executed in the fail case.
Have a great day.
TIC

 

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

 

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

 

0 Kudos
220 Views
variable_andrew
Senior Contributor I

So the end solution for me is an recurring theme I'm having with all the FLASH related SDK code and caching - and the compiler not allocating critical code to internal RAM (appropriately?).

So NVIC_SystemReset, taskDISABLE_INTERRUPTS, vTaskSuspendAll, __disable_irq are all allocated to FLASH.

That means after I update flash and the ^^^ code bits get overwritten, if I try to call any of those functions - who knows what will happen.

So by copying those functions to my own code, and forcing them to be in RAM, I'm able to reset appropriately.

I have similar issues when setting up FLASH  / caching / etc - I have to change a fair bit of SDK code to force inline (instead of just inline) - or change the functions with __RAMFUNC(RAM)

 

So end result is that I'm able to reset now after DFU, but curious as to if there's any plan or flag to be intended to move such functions to RAM?

View solution in original post

0 Kudos
454 Views
mjbcswitzerland
Specialist V

Hi

I use the following on i.MX RT 1011, 15,20,50, 60 and 64 boards.

// This routine is called to reset the processor
//
extern void fnResetBoard(void)
{
    uDisable_Interrupt();
    APPLICATION_INT_RESET_CTR_REG = (VECTKEY | SYSRESETREQ);             // request cortex core reset, which will cause the software reset bit to be set in the mode controller for recognition after restart
    IOMUXC_GPR_GPR16 = (IOMUXC_GPR_GPR16_RESERVED | IOMUXC_GPR_GPR16_INIT_ITCM_EN | IOMUXC_GPR_GPR16_INIT_DTCM_EN); // set the FlexRAM layout back to that taken from the eFuse setting (default configuration) - although the reset is commanded before executing this line it still operates and avoids the RAM layout being changed when the code is still running
    FOREVER_LOOP() {}
}

 

Since I tend to (or always) reconfigure the FlexRAM and disabled OCR partition I need to add the FlexRAM reset so that the bot loader can restart.

The same call is used by the application (to perform soft resets) or the serial loader when it has just loaded new applications to QSPI/Hyper Flash. It seems stable after several months of intensive use.

Regards

Mark

 

0 Kudos
434 Views
variable_andrew
Senior Contributor I

Hi @mjbcswitzerland 

Could you reference those registers? I've not seen

APPLICATION_INT_RESET_CTR_REG

 anywhere before?

 

Thanks for the quick response!

0 Kudos