RT1170 - Field firmware update

cancel
Showing results for 
Search instead for 
Did you mean: 

RT1170 - Field firmware update

Jump to solution
113 Views
mrd
Contributor II

We have a project where an RT1176 based board will be communicating with a PC via USB as a CDC device.

We would like to be able to do a secure firmware update over the USB interface without having to switch any input levels to change the boot configuration.

We are using the RT1170-EVK and MCUXpresso for development. Our custom board will have the QSPI flash, SD Card, and SDRAM - all same as on the EVK.

The current plan is to boot from SD Card where firmware is loaded into SDRAM for execution. This is working fine, but we need to have a firmware update scheme. Can any of you provide suggestions? Keep in mind that we do not want to press a button or change any of the boot configuration input levels such as would need to be done if using the internal ROM's loader.

I've spent some time looking at SDK 10's bootloader_examples Flashloader code.

Please confirm that one option would be to put Flashloader in the QSPI flash and make it the boot device.  Then, if no firmware update is initiated over USB within a timeout period, load the normal application from SD Card into SDRAM and execute.  We would have to provide a way to force RT1176 firmware to do a soft reset and then have our PC side application watch for the Flashloader's USB HID device to become available and communication with it before the timeout expires.  Our PC application would then load firmware into SD Card memory via the API defined in the MCU Flashloader Reference Manual pdf.

For this scheme to work, it looks like we would have to modify Flashloader to take care of the firmware image transfer from SD Card into SDRAM since it doesn't appear to support this now. I understand there is a jump length limitation. Will we be able to jump from the QSPI flash address range into SDRAM?

Another option would be to always boot from the SD Card (and execute from SDRAM) using a Primary and Secondary firmware image scheme. That is, when firmware is being updated, it would first modify the SD Card sectors so that IVT and boot data point to the secondary image.  Then it would update the Primary image on SDCard; change the IVT & boot data back to pointing to Primary image; then copy Primary image to the Secondary image. It would be vulnerable to power-loss just during short time IVT & boot are updated.

This almost sounds simpler than trying to use the Flashloader...anyone have advice on this?

Note that we plan to use Segger Jlink for the initial production programming - so we are mainly just concerned about the field update scheme now.

This forum posting "Need RT1170 FOTA example" ( https://community.nxp.com/t5/i-MX-RT/Need-RT1170-FOTA-example/m-p/1326147 ) from August says that "FOTA SBL will be published in the end of this month". I don't see anything about this when I click on the link for https://github.com/NXP . Is there something in the works that we should wait for?

Thank you for reading this and any feedback you can provide would be greatly appreciated. Or, if you can point me to an applications engineer or web resource that would clear things up, that would be appreciated too. The RT1176 is the first we've used from the iMXRT family and it has been a challenge to comprehend the firmware update schemes and support code available. 

 

0 Kudos
1 Solution
69 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi @mrd 

   Thanks for your updated information.

Please check the follow information from the FOTA:

kerryzhou_0-1631580928540.png

kerryzhou_1-1631580935749.png

You can see, in the SBL, it supports the ISP(UART/USB HID), you can use ISP UART to download code. If you want to use SD card, you need to use SBL+SFW. 

You can consider, SBL is the secondary secure bootloader, and SFW is the firmware which also contains the special download interface, eg, SD card, ethernet etc.

You can use the sd card to install the image, it's OK. you mentioned USB cdc, in fact, it is the UART ISP, the SBL can use the UART download the SFW directly, but your SBL you need to program it with debugger or enter serial download mode to download it.

 About the project, you are right, just contains :

— GCC_ARM toolchain
— or IAR IDE v8.40
— or MDK IDE v5.30

no directly MCUXpresso project now.

 

Wish it helps you!

Best Regards,

Kerry

 

 

 

View solution in original post

0 Kudos
5 Replies
87 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi @mrd ,

   The FOTA is published, please check the following link:

Secure Bootloader(SBL) :
https://github.com/NXPmicro/sbl

Secure Firmware(SFW) :
https://github.com/NXPmicro/sfw

Please download the link code in the github, if you meet any issues, just kindly let me know.

Best Regards,

kerry

0 Kudos
76 Views
mrd
Contributor II

Thank you for letting me know about the SBL and SFW projects.  A lot of work has been done. How do you envision we use SBL and/or SFW for our specific application?  Our RT1176 application will be communicating with a Linux PC (industrial single-board-computer) over USB with RT1176's USB1 configured in communication-device-class (CDC) mode.  We will have the QSPI Flash (16Mbyte NOR U23 on RT1170-EVK) on the board, but had planned on using the SD Card for main firmware storage and execute from SDRAM for maximum performance. I looked through SBL source code and it appears to reside in the QSPI NOR flash, but also stores the update firmware image to the QSPI flash - so we wouldn't be able to use the SD Card for the main firmware image?  

The SFW is for OTA updates from ethernet, SD-Card, or a USB Flash Drive. Are you thinking we should modify SFW to receive the update over CDC USB?

It appears that neither SBL or SFW are available as an MCUXpresso project. Is this correct?  

Thank you.

0 Kudos
70 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi @mrd 

   Thanks for your updated information.

Please check the follow information from the FOTA:

kerryzhou_0-1631580928540.png

kerryzhou_1-1631580935749.png

You can see, in the SBL, it supports the ISP(UART/USB HID), you can use ISP UART to download code. If you want to use SD card, you need to use SBL+SFW. 

You can consider, SBL is the secondary secure bootloader, and SFW is the firmware which also contains the special download interface, eg, SD card, ethernet etc.

You can use the sd card to install the image, it's OK. you mentioned USB cdc, in fact, it is the UART ISP, the SBL can use the UART download the SFW directly, but your SBL you need to program it with debugger or enter serial download mode to download it.

 About the project, you are right, just contains :

— GCC_ARM toolchain
— or IAR IDE v8.40
— or MDK IDE v5.30

no directly MCUXpresso project now.

 

Wish it helps you!

Best Regards,

Kerry

 

 

 

View solution in original post

0 Kudos
60 Views
mrd
Contributor II

Thank you. I will mark this as the accepted solution.

One point of clarification is that SFW looks to only use the SD-Card to supply the firmware image, which is then stored in the QSPI Flash. We don't want the user to have to remove or insert the SD Card. We just wanted to use it for firmware and file storage. Booting from SD Card (where code is automatically transferred to SDRAM for execution on boot-up) seems to work very well on the RT1170 and provides good performance. Plus a majority of the SD Card can be used for non-volatile file storage.

Let me know if I'm wrong, but if we use SBL, it appears we would have to switch to storing firmware in the QSPI flash (and be constrained by the QSPI flash size).  This may still provide good enough performance and enough code space for us though.

0 Kudos
42 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi @mrd ,

   Thanks for your updated information.

   In fact, the SFW is the example for the customer, customer also can modify it by their own demand, eg, if you want to boot from sdcard, then run in internal SDRAM, you totally can copy the code to the SDRAM, and jump to the related address to run it, as i know, the SBL already help you initialize the SEMC, so you can use the SDRAM directly.

 

Best Regards,

Kerry

0 Kudos