iMXRT1064; Issue with firmware swap

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iMXRT1064; Issue with firmware swap

4,710 Views
jaripeltonen
Contributor IV

Hi!

I'm working on iMXRT1064-EVK. I'm currently trying to get firmware swap working on the internal FLASH. I've studied the Application Note AN12255 for iMXRT1060 and implemented/adapted the related SW modifications on top of iMXRT1064 'freertos_hello' demo project. I'm also using the tools and configuration files that are included in 'FLASHLOADER-RT1064-1.0' to create the needed SW images.

As I understand I have the BD files correctly configured; I can get the two SW images successfully created, the first one at 0x7000 0000 and the other one at 0x7020 0000. Also the SB files should be ok and the eFUSE is correctly programmed, I have checked this (0x0008 0000 at 0x6E0).

I use MfgTool for programming the SW images and this also works ok.

The issue is that when I tell the SW to swap to the 2nd firmware, it gets stuck and can only be recovered by Reset. If I change the code so that 'bl_firmware_switch()' swaps "back to the existing image" (at 0x7000 0000) it works. But if the target image is the one at 0x7020 0000, it won't work.

I won't attach any configuration files to this message (yet) as I first want to get your ideas on what I may have done wrong or forgotten to do. Please share any thoughts on this topic, especially if you have succeeded in getting firmware swap working on iMXRT1064.

Thanks for you support!

Best regards,

Jari

Labels (1)
0 Kudos
17 Replies

4,694 Views
jaripeltonen
Contributor IV

Hi,

I have not succeeded in getting firmware swap working so far. I changed to a new project in MCUXpresso, "evkmimxrt1064_hello_world", simply to get rid of FreeRTOS. I implemented the modifications on top of this project, but the result is the same; when the SW tries to switch to firmware 2, it gets stuck. I think there's something wrong in the generated SB file or something wrong in the programming setup. It looks as if the second image is not getting programmed or it is in format that cannot be executed.

I've following questions:

1) I'm using the BD file 'imx-flexspinor-normal-unsigned.bd' for both firmware images, is this correct? I have attached the BD files (as txt files) in here, please let me know if something is wrong in them.

2) Are the commands that I'm using (below) correct?

elftosb.exe -f imx -V -c imx-flexspinor-normal-unsigned.bd -o evkmimxrt1064_hello_world-FW1.bin evkmimxrt1064_hello_world-FW1.s19
elftosb.exe -f kinetis -V -c program_flexspinor_image_qspinor.bd -o boot_image.sb evkmimxrt1064_hello_world-FW1_nopadding.bin

elftosb.exe -f imx -V -c imx-flexspinor-normal-unsigned.bd -o evkmimxrt1064_hello_world-FW2.bin evkmimxrt1064_hello_world-FW2.s19
elftosb.exe -f kinetis -V -c program_flexspinor_image_qspinor_2M_offset.bd -o boot_image.sb evkmimxrt1064_hello_world-FW2_nopadding.bin

3) I compared the example .srec files related to AN12255SW example by Meld tool. Why are there so many differences? When I compare my compiled .s19 files for FW1 and FW2, the differences are only related to code that is affected by the compiler switch FIRMWARE_INDEX.

Thanks for any help you can provide on this topic!

Regards,

Jari

0 Kudos

4,677 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello Jari,

Regarding your questions, please see my comments below. 

1) I'm using the BD file 'imx-flexspinor-normal-unsigned.bd' for both firmware images, is this correct? I have attached the BD files (as txt files) in here, please let me know if something is wrong in them.

These BD files that you are using are not correct. When downloading the SDK for the RT1064, you need to select the mcu-boot under middleware. Once you do this, you will need to go to the following path SDK_PATH\middleware\mcu-boot\bin\Tools\bd_file\imxrt106x. The file that you need is program_flexspi2nor_image_qspinor.bd. For the second image, you need to make the changes as mentioned in the application note. 

2) Are the commands that I'm using (below) correct?

Yes, the commands that you are using are correct. 

3) I compared the example .srec files related to AN12255SW example by Meld tool. Why are there so many differences? When I compare my compiled .s19 files for FW1 and FW2, the differences are only related to code that is affected by the compiler switch FIRMWARE_INDEX.

Keep in mind that the software provided within the app note is for the RT1060-EVK. There are some differences between the RT1060 and the RT1064, so it's not a good idea to compare these two files. 

How are you swapping to the second image? 

 

Regards,
Victor

0 Kudos

4,668 Views
jaripeltonen
Contributor IV

Hello Victor,

Thank you for your reply.

Regarding mcu-boot; are you saying that I need to include mcu-boot from middleware in "Manage SDK Components"? I am not seeing mcu-boot in there. I can find it in SDK path, but not as a selectable item in middleware options. I am currently using MCUXpresso v 11.2.1 and SDK v2.8.6.

I can find the directory for BD files in SDK path. And regarding my BD file "program_flexspinor_image_qspinor.bd" (attached), it has the same configurations as the file you referred to, "program_flexspi2nor_image_qspinor.bd", with the exception that I erase the first half of the internal FLASH (2 MB) instead of 256 KB. So it should be ok, right?

The swap implementation I have basically copied from the example project; I copied the files bl_api.c, bl_api.h and flexspi_nor_flash.h and implemented the actual swapping in the 'hello_world' source code.

So, should I be using another/modified version of the file "flexspi_nor_flash.h"?

Regards,

Jari

 

0 Kudos

4,643 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello Jari, 

Regarding mcu-boot; are you saying that I need to include mcu-boot from middleware in "Manage SDK Components"?
Yes, this is what I meant. I just verified that the MCU BOOT is an option within the SDK builder. See the below image. Also, I highly recommend you update to the newest version of MCUXpresso IDE and the SDK. 

victorjimenez_0-1618611041344.png

The swap implementation I have basically copied from the example project; I copied the files bl_api.c, bl_api.h and flexspi_nor_flash.h and implemented the actual swapping in the 'hello_world' source code.
Just to be sure that I understood you correctly, you took files bl_api.c, bl_api.h and flexspi_nor_flash.h from the application note example project and integrate those in a hello_world project for the RT1064, correct? 

Could you please share with me your example project? 

Regards,
Victor 

0 Kudos

4,604 Views
jaripeltonen
Contributor IV

Hi Victor,

 

Thank you for your message! Sorry for the delay in replying to you, I was busy with other things last week.

Please find attached my MCUXpresso example project. I should have all the necessary features, such as mcu-boot, included in my setup as I have selected 'ALL' when buidling the SDK for download. To answer your question; yes, I copied the three source files (bl_api.c, bl_api.h and flexspi_nor_flash.h) from the example project (AN12255SW).

Just for curiosity, when modifying the source code a bit, the SW is able to jump from FW0 to FW0 (i.e. back to original firmware), so it seems that the swap functionality is working at least to some extent.

Please let me know if you find anything wrong in my source code or setup. Thanks!

Best regards,

Jari

0 Kudos

4,588 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello Jari, 

You mentioned the following: 

When modifying the source code a bit, the SW is able to jump from FW0 to FW0 (i.e. back to original firmware), so it seems that the swap functionality is working at least to some extent.

Based on this information it seems that the problem that you are facing is due to the process of loading the second image. Could you please describe the process of how you are flashing the second image? What modifications did you make to the source code that allow you to execute the jump? 

Regards,
Victor 

0 Kudos

4,575 Views
jaripeltonen
Contributor IV

Hello Victor,

Here's the sequence that I am using when creating and programming the SW images into EVK board. I'm working in Windows 10 environment.

1) compile SW image with FIRMWARE_INDEX set to 0

2) convert the compiled .axf file to .s19 format and rename it 'evkmimxrt1064_freertos_hello-FW0.s19'

3) compile SW image with FIRMWARE_INDEX set to 1

4) convert the compiled .axf file to .s19 format and rename it 'evkmimxrt1064_freertos_hello-FW1.s19'

5) copy both .s19 files into the folder where 'elftosb' is

6) create bootable image (FW0)

elftosb.exe -f imx -V -c imx-flexspinor-normal-unsigned.bd -o evkmimxrt1064_freertos_hello-FW0.bin evkmimxrt1064_freertos_hello-FW0.s19

elftosb.exe -f kinetis -V -c program_flexspinor_image_qspinor.bd -o boot_image.sb evkmimxrt1064_freertos_hello-FW0_nopadding.bin

7) copy 'boot_image.sb' into directory ...\mfgtools-rel\Profiles\MXRT106X\OS Firmware

set 'name=MXRT1064-DevBoot' in cfg.ini for MfgTool

9) increase timeout to 90000 for body="receive-sb-file ..." in file  'ucl2.xml'

10) set device into Serial Download mode

11) start MfgTool

12) create bootable image (FW1)

elftosb.exe -f imx -V -c imx-flexspinor-normal-unsigned.bd -o evkmimxrt1064_freertos_hello-FW1.bin evkmimxrt1064_freertos_hello-FW1.s19

elftosb.exe -f kinetis -V -c program_flexspinor_image_qspinor_2M_offset.bd -o boot_image.sb evkmimxrt1064_freertos_hello-FW1_nopadding.bin

13) copy 'boot_image.sb' into directory ...\mfgtools-rel\Profiles\MXRT106X\OS Firmware

14) start MfgTool

The BD files that I'm using I have attached already earlier in this thread (see above). Note that I am using the same 'imx-flexspinor-normal-unsigned.bd' for both FW0 and FW1, I assume this is correct.

Programming of both SW images succeeds ok, no issues seen there.

Please let me know if you see any errors in my sequence or BD files.

Thanks and best regards,

Jari

0 Kudos

4,532 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello Jari, 

Thanks for the detailed response. I'm making some tests on my side. I will give you an update as soon as possible. 

Regards,
Victor 

0 Kudos

4,519 Views
jaripeltonen
Contributor IV

Hello Victor,

Any news on this topic? Did you succeed in getting firmware swap working?

Best regards,

Jari

0 Kudos

4,488 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello Jari, 

I'm still checking this internally, I will give you an update as soon as possible. Thanks for your patience. 

Regards,
Victor 

0 Kudos

4,449 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello Jari, 

If you read the memory at blocks 0x70000000 and 0x70200000, are you able to see the firmware images written correctly? 

Regards,
Victor 

0 Kudos

4,362 Views
jaripeltonen
Contributor IV

Hi Victor,

 

I added a few lines in the flashing sequence to verify that flashing of SW images is successfully executed. The attached document shows the results. MfgTool is also indicating an OK result when flashing the SW images.

Have you succeeded in getting FW swap working on your HW?

 

Thanks & Best regards,

Jari

0 Kudos

4,334 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello Jari, 

Since it seems that the swap is working correctly back to the first image, we think the swap functionality is okay, maybe the problem is somewhere else. 

We would recommend reading back the IMAGE_OFFSET fuse to make sure it's configured correctly. It seems the bd file is configuring it correctly, but since it's not working, it's still worth checking at this point. 

Could you also send the binary firmware images you are writing into memory? FW1_nopadding.bin and  FW0_nopadding.bin. 

Regards,
Victor 

0 Kudos

4,274 Views
jaripeltonen
Contributor IV

Hi Victor,

Thanks for your reply.

You were right, the issue is in the eFUSEs. I must have tried firmware swap earlier with a different image offset, as the eFUSE value for image offset is 0xC, i.e. 12 x 256 KB = 3 MBytes.

As I cannot clear the eFUSE, I modified the bd file for the second FW image so that it would locate into address 0x7030 0000. When tried this out, the result is the same as earlier; fw swap from image-0 to image-0 works but not from image-0 to image-1.

I also noticed, that when the fw swap fails, if I connect USB cable to the EVK board and MfgTool is still running, MfgTool detects the EVK as USB HID device. So, I guess the SW is stuck in a way that the device is put into Serial Download mode?

Please find attached the binary files I have created. Maybe you could try them out in your setup?

Thanks for your support!

Best regards,

Jari

 

Tags (1)
0 Kudos

4,182 Views
victorjimenez
NXP TechSupport
NXP TechSupport

Hello Jari, 

Could you please share the bd files with the modifications that you made? Also, when compiling the image did you make the proper changes based on the new address? 

Regards,
Victor 

0 Kudos

4,241 Views
jaripeltonen
Contributor IV

Hi Victor,

 

Have you succeeded in getting firmware swap working on your HW?

Please let me know if you found issues in the files that I have sent.

Thanks & best regards,

Jari

Tags (1)
0 Kudos

3,701 Views
jaripeltonen
Contributor IV

Hi Victor,

Sorry for not being active on this topic for ages. I have been busy with other topics.

Actually, lately I have been busy with implementing FLASH programming functionality. I can now program another SW image into the internal FLASH, in addition to the one that is currently running. I read the new SW image out from a USB memory device and program it into the upper half of the 4 MByte internal FLASH address space (starting at 0x7020 0000). And with this setup I have succeeded in getting firmware swap also working. So, we don't need to care about MfgTool and bd files any more!

My next question is related to booting up the device after programming the new SW image into it.

There are two things;

1) Right after programming the SW image, I tell my SW to do bl_firmware_switch() and this works ok; the device boots up and runs the newly programmed SW ok.

2) But if I then power off the device and power it back on, it seems to boot up the "old" SW image (located at 0x7000 0000).

So, my question is, after a successful programming sequence, is there a way to tell the processor to "automatically" run SW from the higher FLASH area (0x7020 0000)? Or does it always start by running SW from the "default" location (0x7000 0000)? Is the only way to select between the two SW images by setting up some specific flags in e.g. EEPROM and based on these flags add in my boot routine the command to switch to wanted firmware?

Thanks for your patience and for your support!

Best regards,

Jari

 

0 Kudos