Hello CircuitDojo Community,

I am developing firmware on a Sparkfun Thing Plus nRF9160 board, and recently got some good help here regarding Zephyr out-of-tree driver authoring. I’m now working to extend a Nordic sample app, the ncs/nrf/samples/nrf9160/aws_iot sample project from Nordic’s nrf-sdk version 1.6.1. I’m able to build and to flash this sample to the Sparkfun Thing Plus. A next natural development step seems to be to copy the sample app to a separate out-of-Nordic-SDK location, and build it there.

I’ve copied aws_iot to such a stand alone location. None of Nordic’s sample apps have a ./zephyr/west.yml file, but immediately after copying, I invoke west init in the copy of this app I wish to extend and build on. This action pulls down latest stable Zephyr release, but build fails for lack of thing91_nrf9160 directory and board files in `[stand-alone-location]/aws_iot/zephyr/boards/arm/.

Though I’m calling west init && west update inside a copy of aws_iot it appears I’m getting latest stable Zephyr code release and board files, rather than Nordic’s fork of Zephyr and Nordic’s choice of supported boards in nrf-sdk.

Copying ncs/nrf/boards/arm/thingy91_nrf9160 to [stand-alone-location]/aws_iot/zephyr/boards/arm/ resolves that first issue of “board not found”. Next issues are a series of undefined CONFIG_ type symbols. I’ve spent some hours now locating these symbols defined in Kconfig files of Nordic’s nrf code base. Where it made sense I copied a couple Kconfig file over to the “stand alone” app area. Elsewhere I amended one aws_iot Kconfig to point to other Kconfigs, each time resolving some of the undefined symbols errors. This effort however does not seem like the correct way to extract one sample app from a larger SDK and extend it with additional code. And I’m not out of the woods with these errors yet.

Is there a more straight-forward or correct way to determine a sample app’s dependencies? Is my thinking right or wrong, that a sample app may be copied away from its SDK samples folder and then extended from that copy?

Thirdly, how can one track down a sample app’s dependencies? I find no west.yml manifest file in the sample app folder nor a .west/module.yml file. The sample aws_iot CMakeLists.txt doesn’t give much clue for dependencies either.

In aws_iot the file prj.conf expresses which radio and run time features are enabled, but doesn’t make most of those features known to Zephyr’s build tools. The other sample app files don’t seem to express any specific references to modules nor libraries such as mqtt either:

Kconfig
prj.conf
prj_qemu_x86.conf
sample.yaml

Am I going about this wrong, or is it reasonable to copy a single app and build it outside of nrf-sdk?

  • Ted

    tedhavelka66 you should check out how I formatted the Air Quality Wing demo. For sanity, I always include a west.yml in the top level project. That way you can successfully initialize your project’s dependencies (including Zephyr) This will clone the whole of zephyr in the new location though. If you want to use your existing SDK, you should place your files within your current clone of the SDK.

    https://github.com/circuitdojo/air-quality-wing-zephyr-demo

    Remember you only need west.yml if you’re completely outside a copy of Zephyr. If you are within a Zephyr working directory it’s not necessary to run west init etc as it’s already initialized.

    In the case of my demo code my west.yml looks like the following:

    manifest:
  remotes:
    - name: nrfconnect
      url-base: https://github.com/nrfconnect
  projects:
    - name: nrf
      repo-path: sdk-nrf
      remote: nrfconnect
      revision: v1.6.1
      import: true
    # Drivers repository
    - name: air-quality-wing-drivers
      path: aqw
      revision: main
      url: git@github.com:circuitdojo/air-quality-wing-zephyr-drivers.git
      import: true
    # Golioth repository.
    - name: golioth
      path: modules/lib/golioth
      revision: b59c21bafc78a57a38b9094cda33c453a8bed38d
      url: git@github.com:golioth/zephyr.git
    # QCBOR
    - name: qcbor
      revision: 3427dee6898da78a509c2259cee65960011d775c
      path: demo/golioth/lib/qcbor
      url: git@github.com:laurencelundblade/QCBOR.git
  self:
    # This repository should be cloned to 
    path: demo

    It pulls in NCS, the Air Quality Wing device library, Golioth (currently not used) and QCBOR. You can see I’ve called out the revisions and git URLs for each so they can be cloned to their respective locations. This is the place you’ll want to look to understand your higher level dependencies. You can, of course, dig deeper into the sub dependencies in their respective west.yml files but it’s generally not necessary. If you do need to make a change, I recommend you add your dependencies to the top level always.

    Hope that helps.

      Hello @jaredwolff , thank you much. I actually have reviewed this AQW Demo manifest file, and used it to model a manifest file in the Kionix out-of-tree driver work I was developing a couple weeks ago. That guidance of yours was key and has me to the point of reading back a manufacturer ID string and part ID. Thank you there!

      It looks like your AQW manifest entries have evolved some over the past ten days. I think my question still stands, however: how may I divine a given sample app’s dependencies? Is the brute force way to capture such dependencies to pull in all of nrf-sdk from the project at url-base https://github.com/nrfconnect?

      You’re looking for a detailed list of all the dependencies that west pulls in? I don’t think that exists but maybe west has that function?

      In general there are two things that affect dependencies:

      1. What you define in your prj.conf
      2. What you include in your west.yml

      After building an example you can go to build/zephyr/.config and look at the contents. That will show with functionality is turned on and what is off. That has ultimate control on what’s included in your final output binary.

      Hope that thelps!

      Terms and Conditions | Privacy Policy