• State Not Answered
  • Replies 16 replies
  • Subscribers 75 subscribers
  • Views 8439 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 270380
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

MCUBoot: Image in the primary slot is not valid!

Farhang

Hi Nordic Team,

I have a custom application running based on nRF NCS 1.5.0 with MCUboot enabled.

I'm having an issue where MCUboot simply doesn't jump to the application.
This comes and goes when I add/remove code from my main application... but with no noticible pattern. I wonder if image size is a factor and thing are overlapping in Flash image...

only using 42% of Flash for app.

1> Memory region Used Size Region Size %age Used
1> FLASH: 207828 B 495104 B 41.98%
1> SRAM: 66368 B 256 KB 25.32%
1> IDT_LIST: 88 B 2 KB 4.30%

Running partition manager report on build...\partitions.yml

I believe this is the standard setup where MCUboot take up to 48K and 2 app banks

flash_primary (0x100000 - 1024kB):
+-------------------------------------------------+
| 0x0: mcuboot (0xc000 - 48kB) |
+---0xc000: mcuboot_primary (0x79000 - 484kB)-----+
| 0xc000: mcuboot_pad (0x200 - 512B) |
+---0xc200: mcuboot_primary_app (0x78e00 - 483kB)-+
| 0xc200: app (0x78e00 - 483kB) |
+-------------------------------------------------+
| 0x85000: mcuboot_secondary (0x79000 - 484kB) |
| 0xfe000: settings_storage (0x2000 - 8kB) |
+-------------------------------------------------+

sram_primary (0x40000 - 256kB):
+--------------------------------------------+
| 0x20000000: sram_primary (0x40000 - 256kB) |
+--------------------------------------------+

I can get more debug but here's some I got via enabling minimal logging via RTT in MCUboot.conf

*** Booting Zephyr OS build v2.4.99-ncs1 ***
I: Starting bootloader
I: det pin = 12 rc = 1
I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
I: Boot source: none
I: Swap type: none
E: Image in the primary slot is not valid!
E: fih_rc=1, succ=0
E: Unable to find bootable image

One clue is.... I started a bit of investigation into "merged.hex" and how it is created. I was surprised to see mergehex.py combines 4 different images with argument "--overlap=replace"

C:\Python38\python.exe C:/depot/ncs/zephyr/scripts/mergehex.py -o C:/depot/application/build_nrf52840dk_nrf52840/zephyr/merged.hex --overlap=replace C:/depot/application/build_nrf52840dk_nrf52840/mcuboot/zephyr/zephyr.hex C:/depot/application/build_nrf52840dk_nrf52840/zephyr/mcuboot_primary.hex C:/depot/application/build_nrf52840dk_nrf52840/zephyr/zephyr.hex C:/depot/application/build_nrf52840dk_nrf52840/zephyr/app_signed.hex

When I looked at those 4 images there is a LOT of overlap. Shouldn't the final image just consist of mcuboot image and app_signed?

For example: "app_signed.hex" and "zephyr.hex" are almost identical, they start the same but app_signed.hex has signature at the end which is normal, see below for similarities at start.

This is strange to me why zephyr.hex needs to be included in the mergehex while app_signed has everything as far as the app goes, or is there a piece that I am missing? 

This is just one clue, but I haven't determined if this is causing the MCUboot not jumping to app. In other times when it does work, the overlap/replace redundancies are still in place. So I'm not sure if this is the cause.

Thanks for your assistance in advance, this is blocking progress of development for us.

Parents
  • 0

    I forgot to mention, I do a clean/ full rebuild, so I assume all hashes are recalculated properly, no?

    I will do more debugging as you suggested and report back.

    RE: overlap=replace, I didn't change the build to this option, it was already set to that. Is that standard or not?

    I guess I can look at an sample/example and see how merge is done for a standard project.

  • 0 in reply to Farhang
    Farhang said:

    I forgot to mention, I do a clean/ full rebuild, so I assume all hashes are recalculated properly, no?

    I will do more debugging as you suggested and report back.

    Okay, sounds good. I'll be waiting for your report

    Farhang said:

    RE: overlap=replace, I didn't change the build to this option, it was already set to that. Is that standard or not?

    I guess I can look at an sample/example and see how merge is done for a standard project.

    Yes, it's standard. It will make it such that the app_signed.hex file is used instead of the zephyr.hex file. Check my answer here for a more detailed explanation:

    "merged.hex will contain the files <your sample>\<build folder>\mcuboot\zephyr\zephyr.hex as well as <your sample>\<build folder>\zephyr\app_signed.hex. If you're building a nonsecure application (nrf9160dk_nrf9160ns) the merged hex file will include <your sample>\<build folder>\spm\zephyr\zephyr.hex also. When you program the merged.hex file, it will program all the mentioned hex files at once."

    Best regards,

    Simon

  • 0 in reply to Farhang

    It seems like 0xBE00 is the thumb instruction for a break point: https://interrupt.memfault.com/blog/cortex-m-breakpoints. However, I still don't understand how the validation for the primary image gets affected by setting breakpoints in MCUboot. Is the before and after comparison done for mcuboot or the primary image?

    It would be nice to get a hold of the application and do some testing myself.

    I have sent you a private message for information on how to share the application

  • 0 in reply to Simon

    I was not able to reproduce this with Ozone. I did the following:

    • Copied /application (the one you sent me over PM) into ncs/nrf/samples
    • Added the following Kconfigs to nrf/samples/application/mcuboot.conf (checked nrf/samples/application/build/mcuboot/zephyr/.config to make sure they were set)

    CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000

    • Built and flashed application + mcuboot: west build -b nrf52840dk_nrf52840 && west flash
    • Opened Ozone and chose the file ncs/nrf/samples/application/build/mcuboot/zephyr/zephyr.elf:

    • Set several breakpoints in main.c:

    • And some breakpoitns in loader.c, to see if the primary image was successfully validated

    • Then I stepped through all the breakpoints, and hit the first breakpoint in loader.c but not the other two after, so it was successfully validated. I also saw that the primary image was booted successfully, since I was able to see the log:

    *** Booting Zephyr OS build v2.4.99-ncs2  ***
[00:00:00.000,366] <inf> adc: nrfx_saadc_init
[00:00:00.000,396] <inf> adc: nrfx_saadc_channels_config = 0
[00:00:00.000,427] <inf> adc: nrfx_saadc_advanced_mode_set=0
[00:00:00.000,427] <inf> adc: nrfx_saadc_buffer_set=0
[00:00:00.000,427] <inf> adc: nrfx_saadc_buffer_set 2=0
[00:00:00.000,457] <inf> adc: BUF_REQ= 0
[00:00:00.000,457] <inf> adc: ppi ass 0
[00:00:00.000,457] <inf> adc: ppi en 0
[00:00:00.000,488] <inf> adc: nrfx_timer_init 0
[00:00:00.000,488] <inf> adc: CC Ticks = 31250

[00:00:00.008,422] <inf> fs_nvs: 2 Sectors of 4096 bytes
[00:00:00.008,422] <inf> fs_nvs: alloc wra: 0, ff0
[00:00:00.008,422] <inf> fs_nvs: data wra: 0, 0
Starting Radar
i=1
   [00:00:01.000,579] <inf> adc: ADC Task 0

[00:00:01.108,764] <inf> main: Read speed unit = 0,MPH, data rate=1
i=2
   [00:00:02.000,671] <inf> adc: ADC Task 1

[00:00:02.109,039] <inf> main: Read speed unit = 0,MPH, data rate=1
i=3
   [00:00:03.000,762] <inf> adc: ADC Task 2

[00:00:03.109,313] <inf> main: Read speed unit = 0,MPH, data rate=1

    Can you confirm that I have understood your issue correctly?

    I noticed now that you were using SES, and the issue might be SES related. Are you able to reproduce your issue with Ozone? Is it sufficient to use Ozone or do you want me to test it with SES as well?

    Best regards,

    Simon

  • 0 in reply to Simon

    Thanks for the info above. 

    You did understand my issue, but I guess 3 things you added are different hence one of these may have fixed the issue.

    - Debug optimizations on - which probably expands the size

    - larger FLASH partition for MCUBoot

    - Ozone rather than SES 5.34a

    I will try above but 2 follow up questions:

    1- Is Ozone the preferred/recommended debugger IDE for nRF NCS or is SES?

    2- Do you know which of the above fixed the issue?

  • 0 in reply to Farhang
    Farhang said:
    1- Is Ozone the preferred/recommended debugger IDE for nRF NCS or is SES?

    Ozone is free to use with our development kits, so both SES and Ozone are valid options to debug with. 

    Farhang said:
    2- Do you know which of the above fixed the issue?

    I tried to comment out the options below, and then set 7-8 breakpoints in bootloader/mcuboot/boot/zephyr/main.c, but I did not encounter any issues with the validation.

    CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000

    I will do some more testing with SES later on

  • 0 in reply to Simon

    I experienced same or similar issue with MCUBoot checking the primary slot hash code and failing when debugging from SES. The workaround or solution that worked for me was to disable the check in MCUBoot conf:

    CONFIG_BOOT_VALIDATE_SLOT0=n
Reply Children
Related
Terms of service