This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unable to find bootable image - MCUBoot

I try to integrate mcuboot and BT DFU into my application. I'm using SDK 1.8.0 and DK board nrf52832.

My problem is, that i got this message "Unable to find bootable image" by mcuboot (investigated via debugger, unfortunatelly  i'm not able to enable logs in that build).
So probably there is problem with partitions or maybe signature of the app.
This is my mcuboot.conf:

CONFIG_MULTITHREADING=y
CONFIG_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_CONSOLE_HANDLER=n

CONFIG_BOOT_SIGNATURE_TYPE_RSA=y
CONFIG_BOOT_SIGNATURE_KEY_FILE="root-rsa-2048.pem"

And this is pm_static.yml:

app:
  address: 0xc200
  region: flash_primary
  size: 0x31E00
mcuboot:
  address: 0x0
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  orig_span: &id001
  - mcuboot_pad
  - app
  region: flash_primary
  size: 0x32000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x3E000
  span: *id002
mcuboot_secondary:
  address: 0x3E000
  region: flash_primary
  size: 0x32000
scratch_storage:
  address: 0x70000
  region: flash_primary
  size: 0xa000
settings_storage:
  address: 0x7a000
  region: flash_primary
  size: 0x6000

And also flash configuration from my .dts:

&flash0 {

	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0xc000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0x0000C000 0x32000>;
		};
		slot1_partition: partition@3e000 {
			label = "image-1";
			reg = <0x0003E000 0x32000>;
		};
		scratch_partition: partition@70000 {
			label = "image-scratch";
			reg = <0x00070000 0xa000>;
		};
		storage_partition: partition@7a000 {
			label = "storage";
			reg = <0x0007a000 0x00006000>;
		};
	};
};

I'm building and flashing using the simplest way:

west build -b <board_name>
west flash (merged.hex is being flashed)

Before some changes (not important here) everything was working fine, and i was even able to upload images through bluetooth with positive answer. But after few rebuilds it stopped working (probably it was pure luck - this is why i suspect that something may be wrong with partition table).

Parents
  • I added the exact same pm_static.yml file and the same prj.conf to the hello_world sample. In addition I enabled CONFIG_BOOTLOADER_MCUBOOT=y in hello_world/prj.conf. It ran without any errors.

    Test it yourself here. I used nrf52dk_nrf52832 and NCS v1.9.0-rc1:

    hello_world_with_mcuboot.zip

    Can you test it yourself and see if you get it to work?

    So based on the information/files you've given me, I'm not sure what may cause it to fail. Could you look at the sample hello_world_with_mcuboot I uploaded and see how that differs from your sample?

      i'm not able to enable logs in that build

    The reason you don't see any logs from mcuboot, is because you disable the (uart)console:

    CONFIG_CONSOLE=n
    CONFIG_UART_CONSOLE=n
    CONFIG_CONSOLE_HANDLER=n

    When I commented these out I was able to get mcuboot serial log to work.

    One question, do you get "Unable to find bootable image" after performing a DFU, or do you get it just when trying to boot the main application?

    Best regards,

    Simon

  • Thanks for quick answer :)

    Problem occurs after regular "west flash" (flashing merged.hex).
    I will now try the example you provided and compare it to my own. In this time, i also attach my zephyr app prj.conf.
    I did some optimization here to save space, maybe I cut too much, please take a look:
    (these setting are for BT DFU application)

    CONFIG_SIZE_OPTIMIZATIONS=y
    
    CONFIG_GPIO=y
    CONFIG_PWM=y
    CONFIG_ADC=y
    CONFIG_NRFX_TIMER0=y
    CONFIG_FLASH=y
    CONFIG_FLASH_PAGE_LAYOUT=y
    CONFIG_FLASH_MAP=y
    
    CONFIG_BT=y
    CONFIG_BT_PERIPHERAL=y
    CONFIG_BT_DEVICE_NAME="nordic"
    
    CONFIG_BT_SMP=y
    CONFIG_BT_LBS=y
    
    # Enable mcumgr.
    CONFIG_MCUMGR=y
    
    # Enable most core commands.
    CONFIG_MCUMGR_CMD_IMG_MGMT=y
    CONFIG_MCUMGR_CMD_OS_MGMT=y
    
    # Ensure an MCUboot-compatible binary is generated.
    CONFIG_BOOTLOADER_MCUBOOT=y
    
    # Allow for large Bluetooth data packets.
    CONFIG_BT_L2CAP_TX_MTU=252
    CONFIG_BT_BUF_ACL_RX_SIZE=256
    
    # Enable the Bluetooth (unauthenticated) and shell mcumgr transports.
    CONFIG_MCUMGR_SMP_BT=y
    CONFIG_MCUMGR_SMP_BT_AUTHEN=n
    
    # Some command handlers require a large stack.
    CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
    
    CONFIG_SPI=n
    CONFIG_I2C=n
    CONFIG_BOOT_BANNER=n
    CONFIG_CONSOLE=n
    CONFIG_UART_CONSOLE=n
    CONFIG_STDOUT_CONSOLE=n
    CONFIG_PRINTK=n
    CONFIG_EARLY_CONSOLE=n
    CONFIG_TIMESLICING=n
    CONFIG_MINIMAL_LIBC_MALLOC=n
    CONFIG_LOG=n
    CONFIG_ASSERT=n
    
    # Disable Bluetooth features not needed
    CONFIG_BT_DEBUG_NONE=y
    CONFIG_BT_ASSERT=n
    CONFIG_BT_DATA_LEN_UPDATE=n
    CONFIG_BT_PHY_UPDATE=n
    CONFIG_BT_GATT_CACHING=n
    CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS=n
    CONFIG_BT_HCI_VS_EXT=n
    CONFIG_BT_CTLR_PRIVACY=n
    CONFIG_BT_CTLR_PHY_2M=n


  • Small update from me. After removing these from mcuboot .conf

    CONFIG_MULTITHREADING=y
    CONFIG_CONSOLE=n
    CONFIG_UART_CONSOLE=n
    CONFIG_CONSOLE_HANDLER=n
    MCUBoot is loading application again. I will investigte deeper and check if DFU is working.
  • Interesting. Yes, let me know if you get it to work or not

  • OK, I think I found the reason. It is not about specific content of mcuboot .conf file . It is about modyfing it itself. After modyfing mcuboot.conf bootloader is being not only rebuilt but also re-generated. 
    But if I do Pristine Build (without modifying bootloader .config) bootloader will no longer load application.
    After any change in mcuboot config file and rebuild (it takes longer then) and flash it starts working again. 

    So maybe mcuboot has to be regenerated every time application is changed?
    Only Pristine Build is causing this error, regular build does not affect starting app by bootloader.
    (after every pristine build i need to modify mcuboot.conf and rebuild again, only after this process bootloader will load app again)

    I guess i'm doing something wrong with building/flashing process.

Reply
  • OK, I think I found the reason. It is not about specific content of mcuboot .conf file . It is about modyfing it itself. After modyfing mcuboot.conf bootloader is being not only rebuilt but also re-generated. 
    But if I do Pristine Build (without modifying bootloader .config) bootloader will no longer load application.
    After any change in mcuboot config file and rebuild (it takes longer then) and flash it starts working again. 

    So maybe mcuboot has to be regenerated every time application is changed?
    Only Pristine Build is causing this error, regular build does not affect starting app by bootloader.
    (after every pristine build i need to modify mcuboot.conf and rebuild again, only after this process bootloader will load app again)

    I guess i'm doing something wrong with building/flashing process.

Children
  • Hi,

    I seem to have a similar problem!


    If I do a complete build (remove build directory, build, flash mcuboot, flash signed application), then it won't start, neither after reset or power-cycle ...

    In that state I rebuild again (just touch CMakeFiles.mak and then build) and flash only the mcuboot again, then the nRF starts as expected ... !?

      $ rm -rf build
      $ west build --build-dir build/ncs src/ncs
      $ nrfjprog -f NRF52 --sectorerase --verify --program build/ncs/mcuboot/zephyr/zephyr.hex
      $ nrfjprog -f NRF52 --sectorerase --verify --program build/ncs/zephyr/app_signed.hex
      $ nrfjprog -f NRF52 --reset

    Now the nRF restarts but immediatly "stops" (consumes ~4.5mA), no logs. nothing ...

    Tries to flash mcuboot again ...

      $ nrfjprog -f NRF52 --sectorerase --verify --program build/ncs/mcuboot/zephyr/zephyr.hex
      $ nrfjprog -f NRF52 --reset

    Same result, just hangs ...
    Build again and flash mcuboot again ...

      $ touch src/ncs/CMakeLists.txt
      $ west build --build-dir build/ncs src/ncs
      $ nrfjprog -f NRF52 --sectorerase --verify --program build/ncs/mcuboot/zephyr/zephyr.hex
      $ nrfjprog -f NRF52 --reset

    Now it starts as expected!! And this is reproducible

    Also strange is that the result differs:

      $ ll build/ncs/mcuboot/zephyr/zephyr.hex
      -rw-r--r-- 1 fange domain_users 126904 feb 10 13:27 /xxxx/build/ncs/mcuboot/zephyr/zephyr.hex

      $ ll ~/tmp/zephyr.hex  <<--- This is a copy of the mcuboot from the "first" build attempt
      -rw-r--r-- 1 fange domain_users 126814 feb 10 13:25 /xxxx/tmp/zephyr.hex

    Must the mcuboot be build "after" the application? Why the difference in size?

    I have just updated SDK from 1.4.1 to 1.7.1 and can't say I have seen this behavior before ... maybe I also am doing something wrong in the build process - but I can't see what.

    Edit!
    I had missed to enable loggin in the mcuboot, and when I did I got the following output:

        *** Booting Zephyr OS build v2.6.99-ncs1-1 ***
        I: Starting bootloader
        E: Bad image magic 0xe58
        E: Unable to find bootable image

    /Thomas

  • Surely we have the same problem.

    Simon, could you please guide us through build and flash process which will allow to build mcuboot with application, that can be run by bootloader? Maybe we miss something. Final conclusion is, that mcuboot is no longer able to start application if pristine build has been performed (or build directory removed).
    After this, mcuboot config has to be touch/modified, and rebuild.

  • Thanks for the additional information and the steps to reproduce. I will look into this/talk to the developers. I'll keep you updated.

    Best regards,

    Simon

  • Dymek117, I will try to reproduce using your steps

    I'm using hello_world_with_mcuboot.zip for all the steps below

    Dymek117 said:
    But if I do Pristine Build (without modifying bootloader .config) bootloader will no longer load application.

    Okay, let me test this. Let's do a pristine build and see if I can reproduce the issue.

    I'm starting now without any build folder. I'm using NCS v1.8.0. I placed the sample hello_world_with_mcuboot inside nrf/samples/

    These are the folders present in my sample

    CMakeLists.txt  README.rst  child_image  pm_static.yml  prj.conf  sample.yaml  src

    Then I do a pristine build, as you mentioned:

    west build -b nrf52dk_nrf52832 -d build -p

    I then flash it to the nRF52 DK using west flash (will automatically flash build folder with name 'build') and I get the following output:

    *** Booting Zephyr OS build v2.7.0-ncs1  ***
    I: Starting bootloader
    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
    I: Bootloader chainload address offset: 0xc000
    I: Jumping to the first image slot
    ÿ*** Booting Zephyr OS build v2.7.0-ncs1  ***
    Hello World! nrf52dk_nrf52832

    So it seems like doing a pristine build works fine here.

    However, maybe you already had a build folder present when you ran pristine build, I will test that as well

    I delete the build folder using rm -rf build, and this is the content of the sample to start with:

    CMakeLists.txt  README.rst  child_image  pm_static.yml  prj.conf  sample.yaml  src

    Let's run a normal build, to generate the build folder:

    west build -b nrf52dk_nrf52832 -d build

    I tried to flash it and everything worked fine, the sample booted.

    Then I tried to do a pristine build

    Dymek117 said:
    I do Pristine Build (without modifying bootloader .config)

    I followed the advice above, by not touching anything. This is the content inside nrf/samples/hello_world now:

    CMakeLists.txt  README.rst  build  child_image  pm_static.yml  prj.conf  sample.yaml  src

    Then I ran the pristine build:

    west build -b nrf52dk_nrf52832 -d build -p

    It worked fine, I got this output:

    *** Booting Zephyr OS build v2.7.0-ncs1  ***
    I: Starting bootloader
    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
    I: Bootloader chainload address offset: 0xc000
    I: Jumping to the first image slot
    ÿ*** Booting Zephyr OS build v2.7.0-ncs1  ***
    Hello World! nrf52dk_nrf52832
    

    I'm using west version 0.12.0, cmake version 3.20.5 and ninja version 1.9.0

    pip3 show -f west
    Name: west
    Version: 0.12.0
    .
    .
    .
    cmake --version
    cmake version 3.20.5
    .
    .
    ninja --version
    1.9.0

    The operating system is Windows 11

    Can you try to follow the exact same steps above with the same sample. If I have misunderstood your steps please tell me. If you run the same steps as me but with a different (failing) result, I would be interested to know more about your environment. What version of the different tools are you using and what OS are you using?

    I think the problem you see is that the hash value the bootloader expects is different from the hash value calculated from the application, this can happen if you modify the main application (which will cause the hash value to be different) and rebuild that, without rebuilding the mcuboot (so it won't get the new updated hash value). However, west build and west pristine build should rebuild both mcuboot as well as the main image when the main image changes (I just tested this).

    I was able to reproduce your behaviour however using these commands:

    • west build -b nrf52dk_nrf52832 -d build1
    • modify main.c
    • west build -b nrf52dk_nrf52832 -d build2
    • dir
      • CMakeLists.txt README.rst build build1 build2 child_image pm_static.yml prj.conf sample.yaml src
    • nrfjprog --eraseall
    • nrfjprog -f NRF52 --sectorerase --verify --program build1/mcuboot/zephyr/zephyr.hex
    • nrfjprog -f NRF52 --sectorerase --verify --program build2/ncs/zephyr/app_signed.hex
    • nrfjprog -f NRF52 --reset

    Got the following output:

    *** Booting Zephyr OS build v2.7.0-ncs1  ***
    I: Starting bootloader
    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
    W: Failed reading image headers; Image=0
    E: Unable to find bootable image

    But this result is expected and not a bug, since I built mcuboot and the main image using from different build folders

    Thomas Fänge, I will look into your steps next week

    Best regards,

    Simon

  • Thanks for deep investigation Simon.

    First difference I see between our setups is that I dont have child_image directory. My mcuboot.conf is on the same level that prj.conf. But "mcuboot" directory is present in /build/ after successful build. Do you think it may cause any difference? (or maybe lack of child_image dir is symptom of some mistakes in configuration, where does this dir come from?)

    Also, small difference about mcuboot is in our cmake files, i set overlay config for mcuboot, like here:

    list(APPEND mcuboot_OVERLAY_CONFIG "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")

    And I see that this is not present in your example, how does build system know to apply settings from child_image/mcuboot.conf? Is this some kind of default location?

    Looking on above differences and your investigation I suspect that my mcuboot is not always being re-generated and rebuilt. But I have no idea why :(

    Thanks.

Related