iMXRT1060 field Firmware update

[palak_shah1]

I am currently trying to figure out how to update the firmware code on nxp iMXRT1060 board while it is in the field with the customer. 

We have a custom design board based on LS1043ARDB and iMXRT1060. LS1043ARDB is the main board and iMX is the daughter board and they are connected using PCIe. 

We have our application running on NXP board. Currently, we are doing XIP from the flash. We use P & E JTAG and MCUxpresso IDE and connect to the board. And use that to download the code to the board. But we will not have a JTAG in the field. 

We have also used MCU boot utility but that requires jumper change, so we cannot use that in field. 

When we are in the field, how do I update the firmware on the nxp board while it is running the old software?

The design is something like this - 

We send a full update of the main and the daughter board in a binary form. The main board will transfer the firmware to the nxp board. But once the nxp board realizes that I got an update, how will it do the firmware update while running the existing firmware?

1) I downloaded the bootloader mcu_boot and flashloader examples. Am I looking at the right place? 

2) Can I integrate the flashloader into our application, change the code so that it always runs from SRAM (instead of XIP) and then use flashloader to update the code in flashm when the update is available? I believe the code is currently set to XIP based on MCU settings. 

3) I read something about SBL. https://github.com/NXPmicro/sbl How is this different from using the flashloader code from the SDK example?

Thanks,

Palak

[palak_shah1]

Hi Jeremy,

Thank you for your reply. I have a few follow up questions - 

1) I see memory map in my project in MCUxpresso. 

The first option under memory Flash name = BOARD_FLASH. Which flash is it referring to? Is it the QSPI flash connected to FLEXSPI1?

On our custom board we have Flexspi1 connected to QSPI and we have another flash connected to LPSPI. 

By default, when I download the code using JTAG where does it download? FLexspi1 QSPI? Or somewhere else? I have not done any initializations of Flexspi1 in my code. 

2) If I get a firmware image that I want to copy of flash, while I am running an existing code, do I have to use QSPI flash connected to FLEXSPI1 to copy the new image to? OR can I use LPSPI flash ? In SBL/SFW code, when it gets an image from external source, it copies to QSPI on FLEXSPI1. is that the only option?

3) Why do you have mcuboot, flash loader, SBL and SFW ? why do different options exist for firmware update? I understand that SBL uses SB and UART and SFW is for Remote OTA, but once the firmware has been received through different sources, do they all use the same underlying process to copy it inside the MCU? To the QSPI flash on FLEXSPI1? 

I am trying to understand that on our custom board ( LS1043ARDB main board connected to IMXRT1060 daughter board), once I receive the firmware, do I have to use FlexSPI1 based QSPI flash to copy the firmware? Can I use LPSPI ?

4) Should I look at SFW or SBL or flashloader code on how to copy the code to flash while executing current code?

Thanks,

Palak

Thanks,

Palak

[jeremyzhou]

Hi，
Thanks for your reply.
1) Is it the QSPI flash connected to FLEXSPI1?
-- Yes.
2) FLexspi1 QSPI? Or somewhere else? I have not done any initializations of Flexspi1 in my code.
-- It's the QSPI, when the RT MCU boots up, ROM code will take the control at first, and it will initialize the FlexSPI or other peripherals for the further bootup process.
3) If I get a firmware image that I want to copy of flash, while I am running an existing code, do I have to use QSPI flash connected to FLEXSPI1 to copy the new image to? OR can I use LPSPI flash ? In SBL/SFW code, when it gets an image from an external source, it copies to QSPI on FLEXSPI1. is that the only option?
-- It's possible to store the new image to the LPSPI flash instead of the QSPI, however, it needs to modify the SBL/SFW code by the developers themselves.
3) Why do you have mcuboot, flash loader, SBL and SFW ?
-- It's an issue left from history.

4) But once the firmware has been received through different sources, do they all use the same underlying process to copy it inside the MCU? To the QSPI flash on FLEXSPI1?
-- Yes, it's almost the same.
5) Should I look at SFW or SBL or flashloader code on how to copy the code to flash while executing current code?
-- You should refer to the SFW.

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

[jeremyzhou]

Hi，
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
1) I downloaded the bootloader mcu_boot and flashloader examples. Am I looking at the right place?
-- In basic, yes.
2) Can I integrate the flashloader into our application, change the code so that it always runs from SRAM (instead of XIP) and then use flashloader to update the code in flashm when the update is available? I believe the code is currently set to XIP based on MCU settings.
-- Yes, it's possible.
3) I read something about SBL. https://github.com/NXPmicro/sbl How is this different from using the flashloader code from the SDK example?
-- The flashloader should be run in the RAM, however, SBL can run in the external flash
4) How will it do the firmware update while running the existing firmware?
-- To implement it, it needs to take advantage of the RTOS to create a task to handle the upgrading process, meanwhile, other tasks still are working.
So the SFW can meet the requirement.
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.
-------------------------------------------------------------------------------