code build issue with mcuboot and mass storage

Hi,

I switched from NCS v2.3.0 to NCS v2.4.0. My code was building correctly with mcuboot and flash disk with NCS v2.3.0, but now I am getting the following error with newer SDK:

For generate the above error, please add below configuration in smp_svr sample:

Please help to solve this build issue with ncsv2.4.0.

Parents
  • Hi,

    I am not able to reproduce the error by adding the configurations you mention in smp_svr sample. Can you upload a project where this can easily be reproduced?

    Best regards,
    Marte

  • Hi,

    Did you try this with ncs v2.4.0.

    I can not upload any project due company policy restriction, smp_svr sample's complete configuration is given below:

    prj.conf: 

    nrf52840dk_nrf52840.overlay:

    child_image/mcuboot/prj.conf:

    child_image/mcuboot/boards/nrf52840dk_nrf52840.overlay:

  • Yes, sample path is correct. Let me install the NCS by Toolchain manager and check with it.

    Actually I need to develop out of tree driver, so I installed the NCS using the below link:

    https://github.com/nrfconnect/ncs-example-application

  • Hi,

    Code build successfully When I installed the SDK by nRF Connect desktop toolchain manager application.

    But I need to develop project for OOT driver.

    Is there any way I can develop my project with OOT tree driver using NCS(Installed by toolchain manager).

  • Hi,

    Did you run west update after updating the revision of the nRF Connect SDK in your repository?

    Using the application as the manifest repository is the recommended method for out-of-tree drivers, but it is possible to install nRF Connect SDK with Toolchain Manager and create an oot driver without west manifest.

    As an example, I have made an oot driver without west manifest. I copied the BME680 sensor driver and simply renamed it to BME681. To use it in an application, I added it with ZEPHYR_EXTRA_MODULES in the application's CMakeLists.txt, for example:

    set(ZEPHYR_EXTRA_MODULES ${CMAKE_CURRENT_SOURCE_DIR}/../out_of_tree_driver_bme681)

    This code is not thoroughly tested or qualified and should be considered provided “as-is”. Please test it with your application and let me know if you find any issues.

    out_of_tree_driver_bme681.zip

    Best regards,
    Marte

  • Yes, I ran the west update as well as pull the fresh SDK but got the same error.

    I successfully tested a sensor using an out-of-tree driver by following the sample you provided, and its working fine.

    Could you please explain the pros and cons of developing an application with oot driver using manifest and without manifest repo?

  • Hi,

    The advantage of using a manifest repo is that you can easily configure the version of nRF Connect SDK, and other repositories, associated with your driver directly in the west.yml manifest file. So it can be more organized in that regard. It is perfectly fine to not use a manifest repo as well, but then you need to make sure that the installed SDK is the correct version associated with your driver.

    Best regards,
    Marte

Reply
  • Hi,

    The advantage of using a manifest repo is that you can easily configure the version of nRF Connect SDK, and other repositories, associated with your driver directly in the west.yml manifest file. So it can be more organized in that regard. It is perfectly fine to not use a manifest repo as well, but then you need to make sure that the installed SDK is the correct version associated with your driver.

    Best regards,
    Marte

Children
  • Thank you for sharing valuable knowledge.

    When I am running combined project then getting following error without manifest:

    Despite increasing the stack size, heap size and thread stack size, the error persists.

    Please help me.  

  • Hi,

    Are you able to figure out which thread it is failing in? You can try to set CONFIG_THREAD_NAME=y in prj.conf to see if you get the name of the thread in the assert, or you can debug the application and enable breakpoints on Zephyr fatal errors to see which thread is running when it asserts.

    Best regards,
    Marte