Sample smp_svr on NRF52840 dongle: .text does not fit in FLASH

Hi,

I am trying to evaluate the provided smp_svr sample with the BLE DFU on the NRF52840 dongle after I have already tested it on the DK.

I get the following error message during the build: zephyr/zephyr_pre0.elf section `text' will not fit in region `FLASH'. Region `FLASH' overflowed by 10876 bytes. I assume the reason for it is the bootloader that is required for flashing the dongle. What do I have to do to get it work on the dongle?

Thank you!

Elias

Parents
  • Hello Elias,

    Since the dongle has a bootloader and MBR from the nRF5 SDK, it means that the flash addresses from 0x00000000 -> 0x00001000, and a chunk at the end (don't remember the address by heart, but this is the old bootloader, and it is located at the "top" of the flash) is already occupied, and you can't remove them.

    Since the mcuboot bootloader from NCS is usually placed on 0x00000000, this will collide with the nRF5 MBR. Therefore, the board files say that you need to stay away from 0x00000000 -> 0x10000000, and it will. The problem however, is that it then tries to fit the bootloader into 0x00001000 -> 0x0000c000, which is a bit too small. Add this to your smp_svr\child_image\mcuboot.conf:

    CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x10000

    This will increase the size of the MCUBOOT parition, so that it can still fit the bootloader even though it doesn't touch the MBR from the nRF5 SDK.

    Best regards,

    Edvin

  • I too have the problem with >west build -b nrf52840dongle_nrf52840 -d build/smp_svr zephyr/samples/subsys/mgmt/mcumgr/smp_svr

    What i don't understand is that this https://docs.nordicsemi.com/bundle/ncs-2.6.1/page/zephyr/boards/arm/nrf52840dongle_nrf52840/doc/index.html

    Is on the website as an example. It relys on files stored in the ncs2.6.1 git repo.

    Yet the command fails. Why aren't the .conf files up to date? Am i suppose to manually go in and change the board config files?

  • Hello,

    Unfortunately, not all samples work with all boards. Perhaps you can share your build log, and we can look into it. 

    It is not recommended to change the board files directly. You can use a an overlay file, called nrf52840dongle_nrf52840.overlay, and place it in a folder called boards in your application's root folder (look at how it is done in most of the samples in NCS). There you can add things that change the default board files.

    Best regards,

    Edvin

Reply
  • Hello,

    Unfortunately, not all samples work with all boards. Perhaps you can share your build log, and we can look into it. 

    It is not recommended to change the board files directly. You can use a an overlay file, called nrf52840dongle_nrf52840.overlay, and place it in a folder called boards in your application's root folder (look at how it is done in most of the samples in NCS). There you can add things that change the default board files.

    Best regards,

    Edvin

Children
  • Whats the best way for submitting output logs? Or even the entire build directory for build/mcuboot and build/smp_svr.

  • save the build log to a txt file, and put everything in a .zip folder, and upload it here (drag and drop).

  • Step 1 pray to Odin that environment sdk and toolchain is somehow setup correctly. A nightmare after moving to 2.9.0 and rolling back.

    Step 2 ensure environment is correctly setup so we can run command outlay in nrf52840dongle_nrf52840

    I created a symbolic link for the mcuboot and the zephyr repo, that feed into the build output.
    mcuboot -> /home/wtr/ncs/v2.6.1/bootloader/mcuboot/
    zephyr -> /home/wtr/ncs/v2.6.1/zephyr/

    Step 3 run first command from option 2
    west build -b nrf52840dongle_nrf52840 -d build/mcuboot mcuboot/boot/zephyr

    Suffer because the toolchains aren't actually working as one would be misled to think with step 1. Notice 2be090971e and b77d8c1312.

    Step 4 Spend the better part of your life searching for a fix ...eventually find the -DNCS_TOOLCHAIN_VERSION flag allows it work when set to NONE or 2.6.1...it seems my environment in terminal was not the only thing needed.
    Get mcuboot to build .. added .zip with log and build dirmcuboot_build_evidence.zip

    Step 5 - FINALLY BACK TO WHERE this message started!

    smp_svr builds and I'm unable to replicate the error stated here

    It's frustrating i don't know why it works or fails sometimes. I'm too busy fighting toolchain and build process that I'm not even looking at the config_xx yy and zz kernam services/sw modules.

  • Ok, I see that you already have your own ticket on the issue, then.

    I believe it would be easier (at least fewer pitfalls) to use the VS Code extension directly to download the toolchain and nRF Connect SDK. Alternatively the nRF Connect for Desktop -> Toolchain Manager. That way you will make sure that the SDK and Toolchains are matching. Then, when building the smp_svr sample, it should automatically build the mcuboot bootloader, and link it with your application. 

    Spector said:
    eventually find the -DNCS_TOOLCHAIN_VERSION flag allows it work when set to NONE or 2.6.1..

    This reminds me of a bug we had at some point. For debugging purposes, is it possible to delete all NCS versions after the one that you are using? I don't recall exactly what version it was, but it may have been around there, where it took the latest toolchain version, even though specifying another one.

    BR,
    Edvin

  • I can start working from only one toolchain.

    The question is which I can't find a dfu tutorial in the intermediate course for 2.9.0, only 2.6.1.

    However running smp_svr sample on v2.6.1 I get


    Running v2.9.0 I get


Related