• State Verified Answer
  • Replies 9 replies
  • Subscribers 75 subscribers
  • Views 480 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 339048
Options

nrf52840dongle_nrf52840 Exceed Flash, with smp_svr sample

Spector

I have looked at forum_post_1, forum_link_2 and forum_link_3.

In short, I am following instructions for my_dongle.

I have ncs 2.6.1.

I have clones of nordics git repos in the proj directory.
--

---mcuboot
 |
 +-zephyr


The mcuboot is 
> git remote -v
>     origin github.com/.../sdk-mcuboot (fetch)
> git status
>     On branch v2.0.99-ncs1-1

The zephyr branch is 
> git remote -v
>     github.com/.../sdk-zephyr (fetch)
> git status
>     On branch v3.599-ncs-1

Following instructions from my_dongle OPTION 2 I am able build mcuboot, and flash using nrfutil (Which btw needs instructions for the rust version that needs to install the pkg before use).

However when I get to the west build of the smp_svr it fails with 

/home/Spector/ncs/toolchains/2be090971e/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: zephyr/zephyr_pre0.elf section `text' will not fit in region `FLASH'
/home/Spector/ncs/toolchains/2be090971e/opt/zephyr-sdk/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/12.2.0/../../../../arm-zephyr-eabi/bin/ld.bfd: region `FLASH' overflowed by 7768 bytes
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
[204/223] Linking C static library zephyr/kernel/libkernel.a
FAILED: modules/mcuboot/mcuboot_subimage-prefix/src/mcuboot_subimage-stamp/mcuboot_subimage-build mcuboot/zephyr/zephyr.hex mcuboot/zephyr/zephyr.elf /home/Spector/work/_play/dongle_play/dongle_smp_svr/modules/mcuboot/mcuboot_subimage-prefix/src/mcuboot_subimage-stamp/mcuboot_subimage-build /home/Spector/work/_play/dongle_play/dongle_smp_svr/mcuboot/zephyr/zephyr.hex /home/Spector/work/_play/dongle_play/dongle_smp_svr/mcuboot/zephyr/zephyr.elf


I get that some configuration tweaks are required in the board config files, but i'm concerned because i would have thought....that a tags version v2.6.1 would be working with the provided examples.

Is Nordic Semi using AI to write documentation? Has a human been involved in the loop testing it?

Is there a stable build i can just use without tweaking the "sample" files.

Regards,
Spector

  • 0 in reply to Hieu

    The goal is using one of our dev boards - be it ubx_bmd360eval_nrf52811 or nrf52840dongle

    In mcuboot (or smp_svr) so I can integrate it with a smp management tool like
    https://github.com/intercreate/smpmgr

    If this works, then I have the fun experience of recreating a DFU ctrl in FreeRTOS.

    With the smpmgr at the moment i get the following responses when in "mcuboot". Whereas I've had no luck communicating with the smp_svr..wtih mcumgr

  • +1 in reply to Spector
    Spector said:
    The goal is using one of our dev boards - be it ubx_bmd360eval_nrf52811 or nrf52840dongle

    Do you intend to use the nRF52811 for your final product? Please know that it has very limited flash memory and you are even more likely to run into the kind of issues you are having here. Using dual slot DFU with it has been very challenging, and we almost always can only recommend single slot (which means no OTA DFU, only over wired connection).

    Spector said:
    In mcuboot (or smp_svr) so I can integrate it with a smp management tool like
    https://github.com/intercreate/smpmgr

    If this works, then I have the fun experience of recreating a DFU ctrl in FreeRTOS.

    With the smpmgr at the moment i get the following responses when in "mcuboot". Whereas I've had no luck communicating with the smp_svr..wtih mcumgr

    The warning seems to say that the client failed trying to read MCUmgr parameters. You could try enabling this: CONFIG_MCUMGR_GRP_OS_MCUMGR_PARAMS.

    Further looking into this kind of issue would be of a different topic, and I would like to ask you to do so over a new DevZone case though, to keep each case focused on a single topic.

    On the original topic, is the Dongle working for you?

  • 0 in reply to Hieu

    The intention is to only update by uart.

    We are only interested in drone remote id (from friendly drones). If we need to update the app. We update the zynq fpga (freertos) this in turn will control the power lines to the nrf52811, so we don't need the smp_svr running as an app per se, just the mcuboot. When restarting, within the dfu wait period the command to read the image will be sent and then if it's deemed to be old it will be updated.

    I will now attempt on sdk nrf v2.9.0 (i'm hoping later is bettter) to implement with config_mcumgr_grp_os_mcumgr_params. I will keep you posted.

  • 0 in reply to Hieu

    Okay - Update is as follows.

    Created a very simple program as per
    https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/applications/nrf_desktop/doc/dfu.html

    Using version 2.9.0

    Added the  CONFIG_MCUMGR_GRP_OS_MCUMGR_PARAMS to the prj.conf.

    I can run the smpmgr and we are partially cooking.


Related
Terms of service