Unable to find bootable image - MCUBoot

RE: Unable to find bootable image - MCUBoot

Simon — Wed, 16 Feb 2022 15:34:41 GMT

Hello Mohamed, could you please open a new case and ask your question there?

Thomas: Even though your issue is kind of related as the initial topic, could you could open a new ticket as well (just link to this ticket and explain the current state), since the initial guy started this post got his issue resolved.

I can see that this ticket has the status "verified answer", so it is locked, so none of you will be able to post any more replies here.

RE: Unable to find bootable image - MCUBoot

Learner — Wed, 16 Feb 2022 15:24:40 GMT

[quote userid="72692" url="~/f/nordic-q-a/84564/unable-to-find-bootable-image---mcuboot/352100#352100"]When I commented these out I was able to get mcuboot serial log to work.[/quote]

Hi Simon,

Apologies if I am intruding in this conversation.

I built hello_world_with_mcuboot project in Segger Embedded Studio (SES) and flashed the merged.hex file in the dev board nRF52833DK. Unfortunately, it is not behaving as expected.

1- I am not seeing the "Hello World!" message.

2- Each time I stop the debugger and restart by clicking 'Go' or F5 I get prompted with the message

"The project zephyr/merged.hex is out of date and needs to be built. Build the project before debugging?"

But I am sure nothing has changed in the project since the last build.

Note, I have not changed anything in the project you provided in the zip file. Should I?

Kind regards

Mohamed

RE: Unable to find bootable image - MCUBoot

Learner — Wed, 16 Feb 2022 10:06:02 GMT

Hi guys,

Can I use hello_world_with_mcuboot example above and build it in Segger Embedded Studio?

Thank you.

Kind regards

Mohamed

RE: Unable to find bootable image - MCUBoot

ecsfang — Mon, 14 Feb 2022 16:13:10 GMT

Hi again,

First sorry for the confusion ...

I'm trying to see what differs between the two builds, and one thing I noticed is in the build/ncs/CMakeCache.txt file.

When it fails, it more or less only differs in the following line:

mcuboot_OVERLAY_CONFIG:INTERNAL=
/xx/vsln-ncs/vt2-overlays/vt2-mcuboot-overlay.conf
/xx/ncs/nrf/subsys/partition_manager/partition_manager_enabled.conf

When it works it looks like this:

mcuboot_OVERLAY_CONFIG:INTERNAL=
/xx/vsln-ncs/vt2-overlays/vt2-mcuboot-overlay.conf
/xx/ncs/nrf/subsys/partition_manager/partition_manager_enabled.conf
; /xx/vsln-ncs/vt2-overlays/vt2-mcuboot-overlay.conf
/xx/ncs/nrf/subsys/partition_manager/ext_flash_mcuboot_secondary.conf

And the .config only differs for mcuboot as I showed in a previous entry:

$ diff build/ncs/mcuboot/zephyr/.config fail_build/ncs/mcuboot/zephyr/.config
265,266c265,266
< CONFIG_PARTITION_MANAGER_ENABLED=y
< CONFIG_FLASH_MAP_CUSTOM=y
---
> # CONFIG_PARTITION_MANAGER_ENABLED is not set
> # CONFIG_FLASH_MAP_CUSTOM is not set

So, it seems as if the config somehow is not correctly setup during a prestine build. The vt2-mcuboot-overlay.conf is included twice, and the ext_flash_mcuboot_secondary is only included in the working build.

The ext_flash_mcuboot_secondary.conf is included in the CMakeFile.txt for the mcuboot, in the file ncs/nrf/modules/mcuboot/CMakeLists.txt:

if (CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY)

# By passing this value we don't require the user to pass any overlay files

# to the MCUboot child image for storing the secondary partition in

# external flash.

add_overlay_config(

mcuboot

${ZEPHYR_NRF_MODULE_DIR}/subsys/partition_manager/ext_flash_mcuboot_secondary.conf

)

endif()

And CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY seems to be configured in the subsys/partition_manager/ext_flash_mcuboot_secondary.conf file, which seems odd since then we have a circular reference ... (the config is set in the file included if the config is set ...) ?

And that is the only content of the file ncs/nrf/subsys/partition_manager/ext_flash_mcuboot_secondary.conf:

CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y

I can't see that this config is set anywhere else ...

Could that be that the MCUBOOT_SECONDARY somehow is not included in the first build, but in the second build the buildsystem gets that the MCUBOOT_SECONDARY should be included ... at least that how I interpret the CMakeCache.txt contents ... that could explain why the bootloader doesn't find the image in the first build.

Best regards,
Thomas

---

RE: Unable to find bootable image - MCUBoot

ecsfang — Mon, 14 Feb 2022 13:59:03 GMT

Hi Simon!

Thanks for your response!

Sorry - I had mixed up my files! It didn't help with creating a child_image etc, it still only works for me after the second build ... :(

I can also confirm that if I create a "child_image/mcuboot.conf"-file:

xxx/src/ncs/child_image$ ll
-rw-r--r-- 1 sefangeth domain_users 1307 feb 14 14:40 mcuboot.conf

then it works!

The configuration for mcuboot we have is normally placed in an overlay file, pointed to from the CMakeFile.txt:

list(APPEND mcuboot_OVERLAY_CONFIG "$ENV{VSLN_NCS_ROOT}/vt2-overlays/vt2-mcuboot-overlay.conf")

So, it seems as if the overlay-file is not used when compiling for the first time (i.e. after deleting the build directory). In the example above - the mcuboot.conf is identical to the vt2-mcuboot-overlay.conf.

Can that be explained - or is the child_image approach to be preferred?

Best regards,
Thomas

RE: Unable to find bootable image - MCUBoot

Simon — Mon, 14 Feb 2022 13:36:25 GMT

Okay, I'm happy it got resolved!

Let me try to look into the issue you encounter Online Thomas Fänge

[quote user="ecsfang"]

I can't really find something in the output when I build (prestine or not), but I saw that in the build/ncs/mcuboot/zephyr/.config it differs between the two builds (prestine build or not):

(The 'build' directory contains a prestine build (i.e. after "rm -rf build"), and no_build is a renamed build-directory after a second build, i.e. after "touch" and build again)

$ diff build/ncs/mcuboot/zephyr/.config no_build/ncs/mcuboot/zephyr/.config
265,266c265,266
< # CONFIG_PARTITION_MANAGER_ENABLED is not set
< # CONFIG_FLASH_MAP_CUSTOM is not set

[/quote]

I'm using this application hello_world_with_mcuboot_v2.zip

I've installed west v0.10.1 to another location. and downgraded NCS to v1.7.0, as it seems that's what you're using.

This is the content of the sample folder to start with:

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

First I check the west version

C:/msys64/mingw64/bin/west --version
West version: v0.10.1

Then I do a pristine build:

C:/msys64/mingw64/bin/west build -b nrf52dk_nrf52832 -d build_v10_pristine -p

Then I created the build folder you refer to as "no_build "

C:/msys64/mingw64/bin/west build -b nrf52dk_nrf52832 -d build_v10_no_build

touch CMakeLists.txt

C:/msys64/mingw64/bin/west build -b nrf52dk_nrf52832 -d build_v10_no_build

Eventually I did a diff between the generated mcuboot folders

diff build_v10_pristine/mcuboot/zephyr/.config build_v10_no_build/mcuboot/zephyr/.config

But I got no result, which means they have the same content

I have not yet installed Dual Boot Linux Ubuntu on my new computer, but I will do it soon and test this on Ubuntu as well.

However, could you try the following:

Update to NCS v1.8.0 and the associated west v0.12.0?
- If you install it through the Toolchain Manager, all the correct tools will be installed automatically
Check how you include the mcuboot config folder. Try to add it to child_image/mcuboot.conf

Best regards,

Simon

RE: Unable to find bootable image - MCUBoot

Dymek117 — Mon, 14 Feb 2022 13:14:17 GMT

Simon, basing on your post with step-by-step described build process I fixed this issue.

Final solution was to create /child_image/ directory and place mcuboot.conf inside this dir.
Then, no additional instructions for this file is needed in cmakelist, it is included by default.
I have no idea why id does matter, but after this small change pristine build is booting fine.

I'm using SDK 1.8.0 on Windows 10. My west version v0.12.0.

RE: Unable to find bootable image - MCUBoot

Simon — Mon, 14 Feb 2022 13:06:19 GMT

Dymek117

[quote user="Dymek117"]My mcuboot.conf is on the same level that prj.conf. [/quote][quote user="Dymek117"]

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")

[/quote]

I tried to modify my sample according to the above, check it out here:

devzone.nordicsemi.com/.../hello_5F00_world_5F00_with_5F00_mcuboot_5F00_v2.zip

Then did a pristine build using NCS v1.8.0:

west build -b nrf52dk_nrf52832 -d build_v12_pristine -p

and it worked fine:

*** 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 tested this with both west v0.12.0 and v0.10.1

Can you upload the project you're using as a zipped file and provide a detailed step-by-step guide on how to reproduce the issue. Could you let me know what west version you're using as well as the OS? You're using NCS v1.8.0, right?

RE: Unable to find bootable image - MCUBoot

ecsfang — Mon, 14 Feb 2022 07:47:24 GMT

Hi Simon,

For your information, I'm building in a Ubuntu (18.04) environment and using West version 0.10.1:

$ west --version
West version: v0.10.1

I can't really find something in the output when I build (prestine or not), but I saw that in the build/ncs/mcuboot/zephyr/.config it differs between the two builds (prestine build or not):

(The 'build' directory contains a prestine build (i.e. after "rm -rf build"), and no_build is a renamed build-directory after a second build, i.e. after "touch" and build again)

$ diff build/ncs/mcuboot/zephyr/.config no_build/ncs/mcuboot/zephyr/.config
265,266c265,266
< # CONFIG_PARTITION_MANAGER_ENABLED is not set
< # CONFIG_FLASH_MAP_CUSTOM is not set
---
> CONFIG_PARTITION_MANAGER_ENABLED=y
> CONFIG_FLASH_MAP_CUSTOM=y

Ie. these two configs are not set in the prestine build, but in the second build they are set - that is the only difference in the .config file between the two builds.

Edit!
I found another difference in the file build/ncs/mcuboot/zephyr/dev_handles.c.
In the prestine build (after rm -rf) the last entry looks like this:

/* 10 : /soc/spi@40023000/mx25u1633f@0:
* - /soc/gpio@50000000
* - /soc/gpio@50000300
* - /soc/spi@40023000
*/
const device_handle_t __aligned(2) __attribute__((__section__(".__device_handles_pass2")))
__devicehdl_DT_N_S_soc_S_spi_40023000_S_mx25u1633f_0[] = { 5, 6, 9, DEVICE_HANDLE_ENDS, DEVICE_HANDLE_ENDS, DEVICE_HANDLE_ENDS };

In the second build, it has changed to:

/* 10 : /soc/spi@40023000/mx25u1633f@0:
* - /soc/gpio@50000000
* - /soc/gpio@50000300
* - /soc/spi@40023000
*/
const device_handle_t __aligned(2) __attribute__((__section__(".__device_handles_pass2")))
__devicehdl_DT_N_S_soc_S_spi_40023000_S_mx25u1633f_0[] = { 6, 5, 9, DEVICE_HANDLE_ENDS, DEVICE_HANDLE_ENDS, DEVICE_HANDLE_ENDS };

Again, no other difference in this file ...

Cheers,
Thomas

RE: Unable to find bootable image - MCUBoot

Dymek117 — Sat, 12 Feb 2022 00:49:27 GMT

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.

RE: Unable to find bootable image - MCUBoot

Simon — Fri, 11 Feb 2022 23:58:32 GMT

Dymek117, I will try to reproduce using your steps

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

[quote user="Dymek117"]But if I do Pristine Build (without modifying bootloader .config) bootloader will no longer load application.[/quote]

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

[quote user="Dymek117"]I do Pristine Build (without modifying bootloader .config) [/quote]

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

RE: Unable to find bootable image - MCUBoot

Simon — Fri, 11 Feb 2022 22:56:09 GMT

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

RE: Unable to find bootable image - MCUBoot

Dymek117 — Thu, 10 Feb 2022 23:27:47 GMT

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.

RE: Unable to find bootable image - MCUBoot

ecsfang — Thu, 10 Feb 2022 12:35:11 GMT

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

RE: Unable to find bootable image - MCUBoot

Dymek117 — Wed, 09 Feb 2022 16:19:44 GMT

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.

RE: Unable to find bootable image - MCUBoot

Simon — Wed, 09 Feb 2022 14:59:29 GMT

Interesting. Yes, let me know if you get it to work or not

RE: Unable to find bootable image - MCUBoot

Dymek117 — Wed, 09 Feb 2022 14:52:57 GMT

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.

RE: Unable to find bootable image - MCUBoot

Dymek117 — Wed, 09 Feb 2022 14:44:26 GMT

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

RE: Unable to find bootable image - MCUBoot

Simon — Wed, 09 Feb 2022 14:18:51 GMT

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:

devzone.nordicsemi.com/.../hello_5F00_world_5F00_with_5F00_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?

[quote user=""] i'm not able to enable logs in that build[/quote]

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