unable to compile application after activating CONFIG_BOOTLOADER_MCUBOOT option

[Alexf]

hello all,

I'm fairly new to nRF SDF and its build environment. I browsed a lot of posts but did not find the solution to what is probably a basic misconfiguration error on my part.

I am using SDK v2.9.1 with Visual Studio Code and the EV-BM833 board.

My application runs fine when in stand alone mode (no boot loader) and now I want to add the bootloader to handle firmware updates in production mode.

I have able to compile, run and debug the MCUbootloder image itself without issue.

The problem is that my application does not compile when I enable the MCUboot option (CONFIG_BOOTLOADER_MCUBOOT=y).
The compilation error being: "zephyr/zephyr_pre0.elf section `rodata' will not fit in region `FLASH'".

From what I could gather, this compilation error means that the CONFIG_BOOTLOADER_MCUBOOT option is actually being ignored (causing the partition manager to not be properly configured).

The application is being built with sysbuild configuration. I tried adding child/mcuboot.conf with CONFIG_BOOTLOADER_MCUBOOT=y with no luck. It tried building without sysbuild too...

I attached my project to that post.

Any help is welcomed,

Best regards,

Alex

8814.peripheral_uart.zip

[Vidar Berg]

Hello Alex,

You may need to reduce the size of the bootloader and your application to make everything fit in flash. Please have a look my answer here for more details:  Problem with flash overflow when adding BLE DFU on nRF52833  

Best regards,

Vidar

[Alexf]

hello Vidar,

I am struggling to find a MCUmgr SMP client that I can just embedded in my stm microcontroller to flash the BM833.

is there such a lib or client available today in C ?

if not, could you point me to a document that describes the commands to send over UART in order to transfer the new application firmware to the bootloader ?

thanks in advance,

Best Regards,

Alex

[Marte Myrvold]

Hi Alex,

There is no official MCUmgr SMP client sample, but a Nordic employee has made an unofficial sample that you can take a look at: https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk/tree/v2.2.0/bootloader_samples/client_smp/smp_client_uart. This code is not thoroughly tested or qualified and should be considered provided “as-is.” Please note that this is tested with nRF Connect SDK v2.2.0 and has not been updated to the latest SDK versions.

Best regards,
Marte

[Alexf]

thank you Marte, I will look closely into that project.

Just out of curiosity, I'm wondering what is the standard route that people usually take to handle the flashing of the app bin via UART if such a client is not available by default ?

Do they modify the mcuboot loader to handle raw flashing directly ?

Best Regards

Alex

[Marte Myrvold]

Hi Alex,

The standard route is to use serial recovery on the device that should be updated and an SMP client on the other device.

Best regards,
Marte

[Alexf]

hello,

I need a little help to finish this update feature. I did things a little differently from the standard route but not that different in the end.

In my bootloader, I activated the UART interface and the mcubootloader receives packets from an external device via UART. The device sends the entire zephyr_signed.bin file and the mcubooloader handles the flashing in the partition0. Partition1 is not even defined in my dts file anymore. Partition0 takes all the space (supposedly).

once flashing is completed (with read back verification), the external device reboots the bm833. On boot, the mcubootloader reads the firmware version in partition0 and the information is correct, this matches the new firmware. Then it goes ahead and boots the application. Note that I have CONFIG_SIGN_IMAGES=y but also CONFIG_BOOT_VALIDATE_SLOT0=n

This is where I am lost. 

After rebooting the BM833, my device receives a string starting with: "*** Booting My Application" which is definitely not coming from my application but instead looks like an output from a standard sample pplication in my device flash. 
I could force erase partition1 to make sure that goes away but I do not want to for the time being.

Second thing that puzzles me: when I start a debug session of my application within Visual Studio Code with the option 'debug without flashing', the target resets (as expected), bootloader starts as well, but then I hit the breakpoint at the entry point of my application code as if everything was normal. 

That I do not understand. Why would the bootloader correctly starts my application through the debugger but not on a hardware reset ?

What am I missing after flashing my application ?

Best Regards,

Alex