Unable to find bootable image

[Learner]

Hello,

From time to time I am getting the error "Unable to find bootable image" when I start a debug session in SES-NE v5.60.

FIH_CALL(boot_go, fih_rc, &rsp);
if (fih_not_eq(fih_rc, FIH_SUCCESS)) {
BOOT_LOG_ERR("Unable to find bootable image");
FIH_PANIC;
}

So, I deleted the whole content of the build folder and re-built the solution and produced a new merged,hex file. But the error persists. If I keep erasing/rebuilding the solution eventually I can start the debug session. Sometimes it takes many retries before it starts working again. I am wasting a lot of precious time that I cannot afford to waste.

Could someone please help sort this problem out ?

Why is this happening randomly?

What can be done to prevent it from happening?

If it cannot be prevented then how can it be fixed without wasting a long time on rebuilding the solution many times?

Thank you.

Kind regards

Mohamed

[Einar Thorsrud]

Hi Mohamed,

When you download the application from SES NE, the image header needed by MCUBoot is missing. So it is expected that MCUBoot will not find a bootable image. When using MCUBoot, you need to flash the merged.hex file, and as this is not done automatically, you need to do it manually. Then you can subsequently debug by selecting to debug without downloading. To avoid this, you could consider testing/debugging without using MCUBoot, or migrating to nRF Connect for VS Code, which is the only IDE we recommend going forward (and also the only supported IDE for the latest nRF Connect SDK releases).

Einar

[mexco]

Hi... I facing same issue with Visual Studio also. After wasting a week, I re-created the same project again, merged my files from faulty project to new.

In VSC, on left side penal, under Actions -> flash is used to run the build, then there is no issue.

But, during Actions->Debug, sometimes same issue occurs of and then. I facing this issue in Asset Tracker sample application, in which I adding custom code. Please suggest solution.

[Earthworn1]

I got the Error again. 

I only get the error when using mbedtls.

I add following Configs and debugging isn't possible anymore.

CONFIG_ANJAY_COMPAT_MBEDTLS=y

CONFIG_NORDIC_SECURITY_BACKEND=n

CONFIG_OBERON_BACKEND=n

CONFIG_MBEDTLS_TLS_LIBRARY=y

CONFIG_MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG=n

CONFIG_MBEDTLS_ENTROPY_C=y

CONFIG_MBEDTLS_CIPHER_MODE_CBC=y

CONFIG_MBEDTLS_CCM_C=y

CONFIG_MBEDTLS_CTR_DRBG_C=y

CONFIG_MBEDTLS_LEGACY_CRYPTO_C=y

CONFIG_MBEDTLS_PK_WRITE_C=y

CONFIG_MBEDTLS_DHM_C=y

CONFIG_MBEDTLS_ECP_C=y

CONFIG_MBEDTLS_ECP_DP_SECP384R1_ENABLED=y

Do you also use MBEDTLS?

[Earthworn1]

Okay i fixed it. The problem are to many breakpoints

[Learner]

Hi,

Sorry I have just seen your message.

Glad you found the root cause.

It is strange that the number of breakpoints can cause the bootloader problems finding the bootable image.

[mexco]

I will test in  my present project on VSC and face same problem just from  a week. After removing all breakpoints, I shall test and tell.

[Martin]

I have the same problems.

I think the problem is associated with the debug probe (Segger J-LInk). These probes have some number of hardware breakpoints (two?) and all other breakpoints will modify the flash with a software breakpoint.
If one starts the application with more active breakpoints than provided in hardware the hash of the application is not the same and the application is not valid and will not be loaded.

So the question is: how to compile MCUBOOT/TFM without the firmware hash check?
Or is there another way to avoid it?

[Einar Thorsrud]

Perhaps you can use CONFIG_BOOT_VALIDATE_SLOT0_ONCE? Then the image is only validated on the first boot, but validation is skipped after that.