Hey, has anybody tried adding Golioth to an existing project on NRF Connect SDK? If so, Id have a couple of questions:
Can Golioth run on a Non-Secure build of my system (nrf9160, using official DK)? I keep getting "undefined reference to soc_secure_mem_read if do try to run the project on NS. Unfortunately, I cant use the modem in a Secure build so im a bit cornered…
Can Golioth be simply added to the project folder, say as an external library, then built with CMakeLists? The documentation in setting it up is a bit vague, so Im having troubles with understanding it…
Sorry if my questions are stupid, as Im an absolute newbie to NRF and Golioth… P.S. regarding question 2, what ive tried:
adding Golioth repo to the nrf west.yml, but then i would get linking errors as the source files would not find headers
as described in github, initializing Golioth with west in my project directory, what then resulted in a hefty amount of linker errors
(currently) Initializing Golioth with west and adding my project files into the new Golioth folder. Compilation stops due to some modules requiring access blocked by Non-Secure build cfg. What is interesting, as Nrf9160 Feather, showcasing Golioth example also uses Non-Secure build cfg, and everything apparenly works for them. (maybe im doing something completely wrong on the way here)
Can Golioth run on a Non-Secure build of my system (nrf9160, using official DK)? I keep getting "undefined reference to soc_secure_mem_read if do try to run the project on NS. Unfortunately, I cant use the modem in a Secure build so im a bit cornered…
All of our Zephyr/Nordic samples for the nRF9160 DK are built as a Non-Secure Zephyr applications. As you pointed out, in order to use the modem, the application for the nRF9160 DK must be built as _ns.
Can Golioth be simply added to the project folder, say as an external library, then built with CMakeLists? The documentation in setting it up is a bit vague, so Im having troubles with understanding it…
Yes, it can; we use that approach with ESP-IDF examples. For reference, see the CMake files in hello sample.
From your post, it seems you haven’t set up the build environment correctly. Adding Golioth Firmware SDK to an existing Zephyr West project is described here. Running the west update command is mandatory in order to clone the newly added Golioth module.
We are big proponents of manifest files, and having a separate environment for each project with a different Zephyr version makes life a whole lot easier. In order to learn more about manifest files, I would suggest you take a look at this blog post.
Thank you for a comprehensive response! Seems like I have some more homework to do . Though I would still want to point out some things I have encountered trying to set up the environment intuitively.
This is (supposedly) the correct way:
Following NCS (NRF Connect SDK) documentation, I created a customized workspace, where, according to Golioth documentation I appended the west file like so:
After running west update, all of the NCS alongside Golioth was placed as external resources in my project file successfully. In this case, when building the application, I would get the following:
warning: attempt to assign the value ‘y’ to the undefined symbol GOLIOTH
What indicates that something is not linking properly.
After such failure, I have proceeded to try different approaches (that are incorrect):
Initialize Golioth directly in a NCS non-custom workspace (in the custom one, I cannot re-initialize west), as per this indication. This resulted in previously stated warning disappearing, but linker errors appearing.
Initialize Golioth SDK for NCS first, then copy my project files over. This resulted in linker errors disappearing, though the project could not compile due to configuration conflicts (Golioth requiring access to secure space, modem requiring the build to be non-secure).
So disregarding the incorrect approaches, I am still confused why doesn’t it link in the (supposedly) correct one?
# The west manifest file (west.yml) for the nRF Connect SDK (NCS).
#
# The per-workspace west configuration file, ncs/.west/config,
# specifies the location of this manifest file like this:
#
# [manifest]
# path = nrf
#
# See the west documentation for more information:
#
# https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/guides/west/index.html
manifest:
version: "0.13"
# "remotes" is a list of locations where git repositories are cloned
# and fetched from.
remotes:
# nRF Connect SDK GitHub organization.
# NCS repositories are hosted here.
- name: ncs
url-base: https://github.com/nrfconnect
# Third-party repository sources:
- name: zephyrproject
url-base: https://github.com/zephyrproject-rtos
- name: throwtheswitch
url-base: https://github.com/ThrowTheSwitch
- name: armmbed
url-base: https://github.com/ARMmbed
- name: nordicsemi
url-base: https://github.com/NordicSemiconductor
- name: dragoon
url-base: https://projecttools.nordicsemi.no/bitbucket/scm/drgn
- name: memfault
url-base: https://github.com/memfault
- name: ant-nrfconnect
url-base: https://github.com/ant-nrfconnect
- name: babblesim
url-base: https://github.com/BabbleSim
- name: bosch
url-base: https://github.com/boschsensortec
# If not otherwise specified, the projects below should be obtained
# from the ncs remote.
defaults:
remote: ncs
group-filter: [-homekit, -nrf-802154, -dragoon, -find-my, -ant, -babblesim, -sidewalk, -bsec]
# "projects" is a list of git repositories which make up the NCS
# source code.
#
# For 'userdata' fields in the projects area, please refer to:
# https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/dm_code_base.html
projects:
# Golioth repository.
- name: golioth
path: modules/lib/golioth-firmware-sdk
revision: main
url: https://github.com/golioth/golioth-firmware-sdk.git
submodules: true
# The Zephyr RTOS fork in the NCS, along with the subset of its
# modules which NCS imports directly.
#
# https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/introduction/index.html
# https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/guides/modules.html
- name: zephyr
repo-path: sdk-zephyr
revision: v3.4.99-ncs1-2
import:
...
Afterward, can you run west update from the <west-workspace> folder and try to build the hello sample located at modules/lib/golioth-firmware-sdk/examples/zephyr/hello ?
Also, are you using nRF Connect SDK v2.5.2? That is the latest version verified by our Continuous Integration system.
It appears that the issue was in versioning, as I was using NCS v2.5.99-dev1 and previously I would use golioth-zephyr-sdk instead of golioth-firmware-sdk, where I absolutely forgot to redefine my CONFIG_GOLIOTH=y to CONFIG_GOLIOTH_FIRMWARE_SDK=y in the config file.
As of now, NCS v2.5.2 with `` golioth-firmware-sdk works perfectly!
. Though I would still want to point out some things I have encountered trying to set up the environment intuitively.