Hi,
Our final goal:
- Be able to write an image from the RAM into a bank of the flash (with a dual bank system)
- After restarting the uP, check the integrity of the image and then boot on this new bank
After reading different documentation we found the document MCUOTASBLSFWUG and reconfigured the RT1020 example to be compatible with the RT1024.
When we load the bootloader generated, in flash, using the software 'LINKFLASH', we can connect via ISP using the software 'MCU-BOOT-Utility'.
First problem if we restart the uP we can no longer connect.
The configuration of the boot pins is '10' internal boot, for the others BOOT_CFGX they are all zero.
Second problem, we try to load our image at the configured address (0x60200000) and the image does not boot.
We set this Defined symbols : XIP_BOOT_HEADER_ENABLE to 0
Our questions are:
- Is the SBL project the most relevant to use to develop our second bootloader?
- After programming our bootloader, is the pin configuration correct?
- Is there a special configuration at the project level on MCUExpresso to make the image bootable with the second bootloader?
Solved! Go to Solution.
Hi @Gaetan
Thank you for contacting us and for your interest!
I just want to understand this phrase better: When we load the bootloader generated, in flash, using the software 'LINKFLASH', we can connect via ISP using the software 'MCU-BOOT-Utility'.
First problem if we restart the uP we can no longer connect.
After programming the ported SBL, do you see this bootloader executing ? After testing by loading a blinky with the LINKFLASH on RT1024, I had to make a reset to see the blinky running. The SBL prints to UART, when it is running. Have you ever seen any bootloader messages?
Regarding - Is the SBL project the most relevant to use to develop our second bootloader?
The SBL is not under active development since 2021, still is is a good reference thanks to the security features and OTA capabilities that it provides. If we check the readme, on the github, you will find that development team recommends the MCU boot opensource project. However, the this project is also not ported for the RT1024, but it is for the RT1020, as I mentioned on this thread
I am not recommending you to jump directly to the MCU boot open source, feel free to pick the option that works better for you. Instead I mention this, in case you want to consider other option, simply because the MCU boot open source is on active development.
Regarding - After programming our bootloader, is the pin configuration correct?
The SBL needs to boot on internal bootloader mode, so I think the boot mode settings are correct.
Regarding - Is there a special configuration at the project level on MCUExpresso to make the image bootable with the second bootloader?
I can not tell, because I do not know all the steps you followed from the SBL user guide. If you follow all the steps, I do not see a missing step to boot the target SFW image.
Please correct me, if I am wrong, but I have not seen the SBL for the MCUXpresso IDE tool chain. Which IDE are you using? is ARM GCC instead?
I hope I could help you
Diego
Finally I tested with a hello world image and it works, so we have a problem, but it does not come from the bootloader, nor from the image configuration, but from the code itself.
Thank you very much for your help!
Hi @Gaetan
Thank you for contacting us and for your interest!
I just want to understand this phrase better: When we load the bootloader generated, in flash, using the software 'LINKFLASH', we can connect via ISP using the software 'MCU-BOOT-Utility'.
First problem if we restart the uP we can no longer connect.
After programming the ported SBL, do you see this bootloader executing ? After testing by loading a blinky with the LINKFLASH on RT1024, I had to make a reset to see the blinky running. The SBL prints to UART, when it is running. Have you ever seen any bootloader messages?
Regarding - Is the SBL project the most relevant to use to develop our second bootloader?
The SBL is not under active development since 2021, still is is a good reference thanks to the security features and OTA capabilities that it provides. If we check the readme, on the github, you will find that development team recommends the MCU boot opensource project. However, the this project is also not ported for the RT1024, but it is for the RT1020, as I mentioned on this thread
I am not recommending you to jump directly to the MCU boot open source, feel free to pick the option that works better for you. Instead I mention this, in case you want to consider other option, simply because the MCU boot open source is on active development.
Regarding - After programming our bootloader, is the pin configuration correct?
The SBL needs to boot on internal bootloader mode, so I think the boot mode settings are correct.
Regarding - Is there a special configuration at the project level on MCUExpresso to make the image bootable with the second bootloader?
I can not tell, because I do not know all the steps you followed from the SBL user guide. If you follow all the steps, I do not see a missing step to boot the target SFW image.
Please correct me, if I am wrong, but I have not seen the SBL for the MCUXpresso IDE tool chain. Which IDE are you using? is ARM GCC instead?
I hope I could help you
Diego
Thank you for your answer.
Following your advice we switched to MCUBoot.
As we also have an RT1064 uP in our application, we took the example from the SDK for this uP.
The bootloader compiles well, we can load it in flash, but our application does not work, we have a hardfault.
We have tried different configurations, which all lead to the same result.
We do not want, for the moment, to go through the imgtool tool to create a header, this is not very practical, because we are in the development phase, so first, we added a partition MCUBoot_header to the address 0x70040000 of our flash and added the necessary structure. We put our application at the address 0x70040400.
We removed the key verification.
And we have enabled the SINGLE_IMAGE parameter
After loading our program in flash, we restart the bootloader in debug mode.
The bootloader does the header check and it is valid.
When arriving at the jump there is the following code :
vt = (struct arm_vector_table *)(flash_base + rsp->br_image_off + rsp->br_hdr->ih_hdr_size);
cleanup();
__set_CONTROL(0);
__set_MSP(vt->msp);
__ISB();
((void (*)(void))vt->reset)();
at this time vt = 0x0x7004000, which seems correct.
And vt.msp = 0x20020000 and vt.reset = 0x7004071D.
The address of the ResetISR does not match that of the .map which is = 0x7004071C.
We tried to hardcode the address, but the result is the same.
Do you have any advice?