Is the mcuboot supposed to be running during application time?

~Using nrf Connect sdk and toolchain at version V2.9.0

Attached is the app.zip project.

0334.app.zip

Basically it consists of a single main funct that prints ("AAAAAAAAAAA") to the screen.

What I've discovered is that during app runtime (when AAAAA ...is being printed to rtt) I can communicate with mcumgr or smpmgr

I want to put another application onto slot 0.

app2.zip

The output of the .bin files is show below

❯ find . -iname "*.bin"
./app/build_sdk_guide/app/zephyr/zephyr.bin
./app/build_sdk_guide/app/zephyr/zephyr.signed.bin
./app/build_sdk_guide/mcuboot/zephyr/zephyr.bin
./app2/build/app2/zephyr/zephyr.bin



Now the question(s) part.

  1. Why is mcuboot running during application runtime?
  2. Can I get it to only run during bootup? In the app dir under the .git logs you can see I have a file called my_defconfig....which is some of the behaviour i wanted during the mcuboot bootup.
  3. When trying to "mcumgr --conntype=serial --connstring='dev=/dev/ttyACM0,baud=115200' image upload $path/app2/zephyr/zyphyr.bin" I am unable to flash it. Using v2.6.1 and a west build command with -DMCUBOOT_OVERLAY_CONFIG we were able to get a app_update.bin generated. This allowed mcumgr to do a firmware update.
  4. Do I need to have mcuboot config info in the app2 build? The plan was to never jtag or nrfproj the chip again. All dfu would be done by uart during bootup, such that we only ever overwrite the slot 0 / app.

Regards,

  • Okay, I can see that. -___-

    Do you have any suggestions on how to reduce RAM usage.

    We can't use nordic chips if it's impossible to have a serial bootloader and a simple app that just prints A to the screen.
    There must be a trick that we've missed.

    I'm sitting on commit #e9457f6576 of https://github.com/hellesvik-nordic/samples_for_nrf_connect_sdk.git
    working on the

    mcuboot_serial_recovery_uart_sysbuild

    and the only change was to create a build configuration with the board
    --board ubx_bmd360eval/nrf52811

  • Hi,

    The nRF52811 is quite limited on RAM, but you should have no problem adjusting the RAM usage of this sample. Generally, default buffer sizes etc will not fit all use cases and need adjustment. As MCUboot does not fit in RAM here, you need to look at MCUboot memory usage. There are several tools that can help, but having a quick look in build/mcuboot/zephyr/.config after building the project I notice a very large main stack size. Maybe you can just reduce that? I would test first by setting CONFIG_MAIN_STACK_SIZE=6144 in sysbuild/mcuboot.conf. With that it builds, but you need to test to see if this stack size is actually large enough run time (I have not done that).

Related