nRF1960 and Out-of-tree Zephyr new driver development?

RE: nRF1960 and Out-of-tree Zephyr new driver development?

tedhavelka — Wed, 29 Dec 2021 21:28:35 GMT

Hello again Pawel,

I amend my statement just after the west.yml code excerpt, near end of my reply this hour: if and when in your project you are able to invoke `west update` and confirm that you are now downloading, or having `west` at minimum check that your copy of `zephyr-driver-work-v2` is up to date, you should be poised to add a line to your app's `prj.conf` file, to enable this sensor. In my driver demo's prj.conf, the one line which "turns on" and includes all the out-of-tree driver details is:

CONFIG_KX132_1211=y

The symbol which I actually wrote in the driver code is `KX132_1211`, but somewhere the actions of, I am guessing, Kconfig language and parser converts my symbol and prepends `CONFIG_` to the beginning of that symbol.

I think you already have this symbol in a prj.conf or other project config file, otherwise you would not have that "undefined symbol" error.

On a few occasions this year 2021, I encountered the error "attempting to assign 'y' to undefined symbol" when I had failed to reference needed third party repositories in my project manifest file. I am also still trying to wrap my head about the way in which the `west` utility reaches up into the parent directory above my local cloned app repository, and populates the other project dependencies (code repos) there. The top location(s) and hierarchy of `west` workspaces is a little different than I am used to seeing in my prior C based, embedded and other project experiences.

This reminds me, while you may not need write your own out-of-tree Zephyr device drivers, the following blog post by engineer Jared Wolff has been an excellent resource to me:

* https://interrupt.memfault.com/blog/building-drivers-on-zephyr

I also highly recommend to visit Jared's technical help forum at https://community.jaredwolff.com/. Mr. Wolff is knowledgeable, responsive, patient and enthusiastic. All great qualities for an engineer working in these fields and collaborating with other developers and teams. I've posted my technical, Zephyr and nRF9160 related questions there on several occasions and always received prompt, useful help. Definitely another technical forum worth visiting!

- Ted

RE: nRF1960 and Out-of-tree Zephyr new driver development?

tedhavelka — Wed, 29 Dec 2021 20:36:02 GMT

Hello Pawel,

Regarding your questions, I was eventually able to solve these problems of header files not found, and a Kconfig symbol I'd created for the KX132-1211 not being defined. I may be able to help.

First, apologies that I did not return and post my solution, so that Nordic team could close this ticket. The summary solution I can share is that I needed to write a correct `west` manifest file for my Zephyr based app.

Second, a couple of comments: I'm working in a Linux environment at the command line, and relying regularly on the Python based `west` utility, and cmake and friends. Second comment, forgive me if I state things that are basic or obvious. I don't mean to underestimate your project. experience.

So I created this tiny app to exercise Kionix driver which I am developing. The `west` manifest file pulls together three git repositories, to form a complete, build-able project. These repositories are Nordic's nrfconnect/sdk-nrf/releases/tag/v1.6.1, zephyr-driver-work-v2, and kionix-driver-demo.

The third of these repositories is my app. This is the code in which you'll find `int main()`. I'd seen somewhere this past year among Zephyr RTOS tutorials and how-tos, a recurring theme: "Zephyr projects are app centric". It has taken me a while to understand this statement. But I'm finding it accurate and true. The simple driver demo above pulls in the much larger coding projects of ncs, and the out-of-tree driver, each of these as code dependencies much like libraries. In this sense my app is my starting point, and the west.yml manifest file is really what makes this so.

Your starting point naturally is different. I can see this from the path you name, `nrfConnectSDK/v1.8.0/...`. Without knowing more detail about your project, I am curious to know whether your west.yml manifest file references the Kionix driver code at kionix-driver-demo? If not, this may be part of the reason you're getting the "no such [header] file or directory" and "attempting to assign 'y' to undefined symbol" errors.

Here is the brief `west` manifest file which I use to build my driver testing app:

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: zephyr-driver-work-v2
      path: kionix-drivers
      revision: main
      url: https://github.com/tedhavelka/zephyr-driver-work-v2
#      import: true   ...2021-08-26 for some reason this should be commented out - TMH
  self:
    # This repository should be cloned to 
    path: kionix-driver-demo

I'm wondering what happens if you add the lines 11..15 to your app's west.yml manifest file, and then invoke `west update`. If this works as I expect, you should get a copy of the Kionix out-of-tree driver project, in a directory that's located at the top dir of your west workspace.

One other caveat: I have not finished the KX132-1211 driver. I've only developed that driver minimally so far, enough to obtain x, y, z axis acceleration readings, and I believe to set output data rate. Does Pinetime Hypnos or another part of your work depend on a complete Kionix KX132-1211 driver?

I am curious to hear whether any of this helps you resolve your build errors. Keep safe,

- Ted

RE: nRF1960 and Out-of-tree Zephyr new driver development?

kapollo — Wed, 29 Dec 2021 00:32:38 GMT

Hi guys I've been trying to build the drive that Ted mentioned, I assume it's already patched/changed, well the problem is I can't build it...
I get :

nrfConnectSDK/v1.8.0/nRF9160-work/nRF9160-work-main/kionix-work/app/src/main.c:17:10: fatal error: kx132-1211.h: No such file or directory
17 | #include "kx132-1211.h"
| ^~~~~~~~~~~~~~

The main reason I came here is that I get similar problems (to the original problem Ted had with the:

attempt to assign the value 'y' to the undefined symbol

I'm trying to build pinetime hypnos with ncs, and it doesn't work apart form other problems I have/had I cannot move over this one. So I guessed I will try to find something that actually works (I've already established that for some reason Kconfig is part of the problem) under ncs.
As I've researched over the Internet it seems its some kind of generic problem people have with out of tree or local drivers directory, all methods, guidelines are mostly it seems for pure Zephyr, not for creations like ncs.

So to build this repo from Ted's github I'm using Windows with ncs (1.8.0) installed with toolchain manager.
I put Ted's repo into main 1.8.0 and then under bash (opened from toolchain manager)
I call :
west build -b nrf9160dk_nrf9160_ns kionix-work/app

and it ends up with the error like pasted above.

I have some experience with ncs, but all I've been doing was fairly simple, not touching custom drivers presented in this very fashion (as out of tree driver), nor had to touch Zephyr's build system that much.

Now I guess that since the error is about not finding the include file (and I assume that if everything is setup correctly it should be just picked up like that) there is still some kind "wrongness" there (or change in ncs/Zephyr).

I would be grateful if someone could tell me how to exactly build it under ncs (it should help me move forward with hypnos I believe)

Best Regards,
Pawel

RE: nRF1960 and Out-of-tree Zephyr new driver development?

Sigurd — Tue, 24 Aug 2021 17:26:02 GMT

[quote user="tedhavelka"] I've applied the patch you sent, and achieved an error-free compilation on my local workstation's experimental kionix code repo.[/quote]

Great 🙂

[quote user="tedhavelka"]Somewhere in the Zephyr build toolchain, a _CONCAT_ macro receives a NULL parameter, so a comlete device symbol cannot be properly generated.[/quote]

Could be that the board overlay you had is not being applied (correctly) for the board you are building for.

/*
 *  https://community.jaredwolff.com/d/73-accelerometer-example-failing-to-compile-on-feather-v2/2
 *  https://www.youtube.com/watch?v=sWaxQyIgEBY  --- Device Tree Deep Dive
 */

&i2c1 {
        compatible = "nordic,nrf-twim";
        status = "okay";
        sda-pin = <26>;
        scl-pin = <27>;
        kionix_sensor: kx132-1211@1f {
                compatible = "kionix,kx132-1211"; 
                reg = <0x1F>;
                label = "KX132-1211";
        };  
};

RE: nRF1960 and Out-of-tree Zephyr new driver development?

tedhavelka — Tue, 24 Aug 2021 17:00:19 GMT

Thank you Sigurd,

The links you have sent regarding Zephyr UART driver example and related materials, plus the diff.patch file are turning out helpful. I've applied the patch you sent, and achieved an error-free compilation on my local workstation's experimental kionix code repo. I pushed those diffs to Github, then cloned the same project to a distinct place on my workstation.

In this `git push; git clone` test, the build in the newly cloned kionix project failed at a much later stage. I don't have the exact message on hand, but that message appears to regard a device symbol that's missing an element. Somewhere in the Zephyr build toolchain, a _CONCAT_ macro receives a NULL parameter, so a comlete device symbol cannot be properly generated. I'm looking into this now. I'd seen this before when I'd gotten an 'include file' line incorrect in a CMakeLists.txt file.

The original project instance where I first patched is still building. I'm now making a file by file comparison between this and the newly cloned project. The difference must be something in a git controlled file, as you corrected my code based on what you found on github.

Also I observe that your patch amends two or three Kconfig files. I'm reviewing your corrections closely to understand the modified syntax.

Thank you again, Sigurd. I am looking forward to grasping cmake and Kconfig better soon. I will keep yourself and DevZone community posted as to my progress.

- Ted

RE: nRF1960 and Out-of-tree Zephyr new driver development?

Sigurd — Mon, 23 Aug 2021 17:35:09 GMT

Hi,

You might find this useful:
https://devzone.nordicsemi.com/nordic/nrf-connect-sdk-guides/b/peripherals/posts/writing-device-drivers-for-uart-peripherals
https://github.com/Riphiphip/zephyr-uart-driver-example

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/reference/drivers/index.html#device-driver-model
https://docs.zephyrproject.org/latest/reference/peripherals/sensor.html

Is this your driver? https://github.com/tedhavelka/nRF9160-work/tree/main/kionix-work/drivers/kionix

I got it to compile with this change:

Attachment: devzone.nordicsemi.com/.../diff.patch

RE: nRF1960 and Out-of-tree Zephyr new driver development?

tedhavelka — Sat, 21 Aug 2021 04:46:19 GMT

Correction: where I write "in-tree work" I intended to say "out-of-tree work". Second, in my request for an out of tree driver example, I specifically need one which compiles correctly. I have yet to locate a build-able example "out of Zephyr tree" driver with app to demonstrate the driver.