NRF5340 multicore image dfu package not have net core binary

Hi,

I am using NRF5340DK and NCS2.1.0. I am able to have network core source code in my application using multicore (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multi_image.html). 

But I would like to have bin file of custom net core inside zephyr and dfu_package zip file. Please suggest a way to do it.

Parents Reply Children
  •  

    May be I found the issue but not solution.
    So wihen we use hci_rpmsg example as network core, it first configured netcore and then mcuboot. But when we use our own network core firmware as attached smp_svr.zip, it first configured mcuboot and then netcore. 
    But as per nrf/modules/mcuboot/CMakeLists.txt, cpunet_signed_app_hex should be set first and so netcore image is not signed and not added in dfu package. Here is code snippet,


    If my understanding is correct and issue is correct, can you provide guidance to correct the sequece of the configuration.

  • Hi,

    After researching this a bit, I found that the order is indeed the issue.

    Then I asked some of my colleagues, and it turns out that you are not the first one seeing that the multicore sample builds in the wrong order.

    See  NCS 2.0 custom child image + mcuboot build

    As far as I know, there are no configurations you can add to the sample to fix the build order.

    For a workaround, I suggest that you do either of these:

    1. Sign the net core hex file manually using Imgtool and add it to dfu_application.zip manually.
    2. Fork the nRF Connect SDK to add a netcore image in the same way as for example zephyr/samples/bluetooth/hci_rpmsg is added when CONFIG_BT is set.

    Regards,
    Sigurd Hellesvik

  • As per  NCS 2.0 custom child image + mcuboot build. Nordic team is planning to fix the issue.
    We seek your help in below,
    1. Help us to get the issue/ticket link for this issue and plan to fix it.

    2. Please elaborate more about your seconds option

    3. Please share the patch link which is provided in devzone.nordicsemi.com/.../ncs-2-0-custom-child-image-mcuboot-build. (Provided links shows diff from main branch and it is about 140 files!!!!) If you can provie patch for SDK 2.1.0, it will be more useful.

  • Hi

    ErDarshan said:
    1. Help us to get the issue/ticket link for this issue and plan to fix it.

    We have an internal tracker for this issue, but I am not able to share much details from it.

    However, it looks like zephyr will add a new way of building multiple images called sysbuild.
    This might be the better way to do things, but I do not think we have any samples using it in the nRF Connect SDK yet.

    ErDarshan said:
    2. Please elaborate more about your seconds option

    "Sign the net core hex file manually using Imgtool and add it to dfu_application.zip manually."

    dfu_application.zip is just an zip-file wil three things:

    1. signed binary for app core
    2. signed binary for net core
    3. yml file to describe these

    And the build system will use Imgtool to generate these signed binary from the built hex files.

    In that case, I would try to sign with these parameters:

    1. Private key: You should add this to your project manually before production, so might as well do it now. See MCUBoot Custom Key with SMP Server for my unofficial example on this.
    2. Hex file: I guess this would be build/netcore/zephyr/merged.hex

    "Fork the nRF Connect SDK to add a netcore image in the same way as for example zephyr/samples/bluetooth/hci_rpmsg is added when CONFIG_BT is set."

    The rpmsg samples are handeled uniquely in the build system. See if (CONFIG_NCS_INCLUDE_RPMSG_CHILD_IMAGE).
    rpmsg samples are listed in RF5340 Protocols and use cases.

    Use git to fork the nRF Connect SDK.
    Then change one of these to do what you need the custom netcore application to do.

    ErDarshan said:
    3. Please share the patch link which is provided in devzone.nordicsemi.com/.../ncs-2-0-custom-child-image-mcuboot-build. (Provided links shows diff from main branch and it is about 140 files!!!!) If you can provie patch for SDK 2.1.0, it will be more useful.

    Ah, that link seems to have compared the forked repo with the current main 4 months ago. So understandably a lot of files have changed.
    I will ask our developer who created the patch about this.

    Regards,
    Sigurd Hellesvik

Related