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

[Learner]

Hi Einar,

Thank you for your suggestions.

I always download the merged.hex file before I start a debug session as shown below.

Target -> Download zephyr/merged.hex

Most of the time I don't get the error "Unable to find bootable image" but, as I said, from time to time I do and when I do get it, it can take a long time for me to get rid of it by restarting SES IDE many times, disconnecting the DK board, restarting my laptop etc..., hence my frustration. I am aware of VS CODE and we are planning to migrate to it but not right now. Until we do, I am looking for support from Nordic. I am hoping you will be able to provide it.

Thank you.

Kind regards

Mohamed

[Einar Thorsrud]

I see. There is no obvious reason why it should faile sometimes, this should be consistent. Can you try to keep the application identical, and repeat testing, so that you get both a failing and working case? In both cases, dump the flash memory, and compare to see what is different. With that, we should be in a better position to understand where to look more closely.

You can easily dump the entire flash like this:

"nrfjprog --memrd 0 --n 0x80000 > flash_dump.txt"

When you got dumpts from both cases, diff the files to see where there is a difference, and what the difference is.

[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.

[Einar Thorsrud]

Is it so that you only see this issue if you rebuild and debug without selecting Actions -> Flash first? If so, this is as expected, and the reason is that you need to program the full merged.hex as if not, the bootloader will not recognize the application as it has changed, and boot validation will fail. This is the expected behavior when using a bootloader, and the solution is to flash the merged hex file first in this case (for instance with Actions -> Flash), and then debug.