• SupportSoftware

  • Auto-generated DT_N_INST_ type symbols not defined during Zephry app build

Hello CircuitDojo Community,
Have any developers here, working to build Zephyr Project based applications encountered errors of the form:
/home/cpguest/embedded/z1-sandbox-2021-08-26/zephyr/include/devicetree.h:301:40: error: 'DT_N_INST_0_kionix_kx132_BUS_P_label' undeclared (first use in this function); did you mean 'DT_N_INST_0_kionix_kx132_1211'?
301 | #define DT_INST(inst, compat) UTIL_CAT(DT_N_INST, DT_DASH(inst, compat))
There are two such undefined symbols I am up against resolving. The other is DT_N_INST_0_kionix_kx132_P_label. These errors come from a small Zephyr app I am developing, hosted at https://github.com/tedhavelka/kionix-driver-demo.
The code beyond these symbols is not yet complete. My focus right now is to resolve these undefined symbols which prohibit me from coding further, or more likely from seeing next build errors to resolve.
Couple of avenues I have scrutinized include my new sensor’s dts/binding file in the Kionix out-of-tree driver repository, and the board overlay file in the driver demo. I know that some key pound defines are generated from these files. But I suspect too my errors today could have their cause in one or more missing pound includes of Zephyr project headers.
The compile time errors state really only what’s missing, and don’t give much clue as to where to go and address the problem. This seems to be a down side of having the meta-files which are compiled into C code, this further level of abstraction and decoupling. I would love to gain some insight into what further clues if any the build error provides in context of Zephyr RTOS.

  • Ted
  • jaredwolff replied to this.

  • Update: got help and solved this problem. In the driver for Kionix KX132-1211 sensor I am working on, I had a mal-formed DT_DRV_COMPAT assignment. The importance of this device tree macro is emphasized in Jared Wolff’s Memfault blog post, https://interrupt.memfault.com/blog/building-drivers-on-zephyr. The section of the post gives the nxp_pcf85063a as an example DT_DRV_COMPAT value, with a small substitution of underscore character for comma. Quoting the programming need here from Jared’s post:

    This aligns with the compatible = "nxp,pcf85063a"; set in the Device Tree. (Replacing a , with _)

    Though I had read and noted this point a couple weeks ago, I still overlooked it when correcting some device tree labels and macros during a couple of restructure efforts I made to my early Zephyr driver works.

    Thank you Jared (and Nordic Devzone as well) for the help so far! Wanted update and close this particular question as solved. Will pay closer attention to these Device Tree requirements going forward!

    • Ted

    tedhavelka66 you’ll need to match the label entry in your .overlay. So according to your overlay files you’re declaring the label as:

                    label = "KX132_1211";

    So you may need to change in your code:

     dev_accelerometer = DEVICE_DT_GET(DT_NODELABEL(kionix_sensor));

    to

     dev_accelerometer = DEVICE_DT_GET(DT_NODELABEL(KX132_1211));

    Give it a try and let me know how it goes

        jaredwolff Hello Jared. I have tried the change you suggest, and am not quite out of the woods. I can now see from the compile time errors how you were directed to that specific line in main.c, the line:

        dev_accelerometer = DEVICE_DT_GET(DT_NODELABEL(needed_device_tree_node_label_here);

        I effected your change, and commented out an invalid function call, removing one warning. I am still getting a similar failure for what looks like an incomplete device tree symbol. Tail end of build messages here:

        .
.
[187/194] Linking C executable zephyr/zephyr_prebuilt.elf

[194/194] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       41596 B        48 KB     84.63%
            SRAM:       22944 B       256 KB      8.75%
        IDT_LIST:          0 GB         2 KB      0.00%
[30/177] Building C object CMakeFiles/app.dir/src/main.c.obj
FAILED: CMakeFiles/app.dir/src/main.c.obj 
ccache /opt/zephyr-sdk-0.12.4/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -DBUILD_VERSION=v2.6.0-rc1-ncs1 -DKERNEL -DNRF9160_XXAA -DUSE_PARTITION_MANAGER=1 -D_FORTIFY_SOURCE=2 -D__PROGRAM_START -D__ZEPHYR__=1 -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo/build/zephyr/include/generated -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/soc/arm/nordic_nrf/nrf91 -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/nrf/include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-drivers/drivers -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-drivers/drivers/kionix/kx132-1211 -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/modules/hal/cmsis/CMSIS/Core/Include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/modules/hal/nordic/nrfx -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/modules/hal/nordic/nrfx/drivers/include -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/modules/hal/nordic/nrfx/mdk -I/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/modules/hal_nordic/nrfx/. -isystem /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/lib/libc/minimal/include -isystem /opt/zephyr-sdk-0.12.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.2.0/include -isystem /opt/zephyr-sdk-0.12.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.2.0/include-fixed -isystem /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/nrfxlib/crypto/nrf_cc310_platform/include -Os -imacros /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo/build/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -fdiagnostics-color=always -mcpu=cortex-m33 -mthumb -mabi=aapcs -imacros /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=implicit-int -fno-asynchronous-unwind-tables -fno-pie -fno-pic -fno-strict-overflow -fno-reorder-functions -fno-defer-pop -fmacro-prefix-map=/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/ted/projects/zephyr-based/z4-sandbox-kionix-work=WEST_TOPDIR -ffunction-sections -fdata-sections -std=c99 -nostdinc -MD -MT CMakeFiles/app.dir/src/main.c.obj -MF CMakeFiles/app.dir/src/main.c.obj.d -o CMakeFiles/app.dir/src/main.c.obj -c /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo/src/main.c
In file included from /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/toolchain/gcc.h:69,
                 from /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/toolchain.h:43,
                 from /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/kernel_includes.h:19,
                 from /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/kernel.h:17,
                 from /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/zephyr.h:18,
                 from /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo/src/main.c:7:
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo/src/main.c: In function 'main':
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/device.h:80:39: error: '__device_dts_ord_DT_N_NODELABEL_DT_N_S_soc_S_peripheral_50000000_S_i2c_9000_S_kx132_1211_1f_ORD' undeclared (first use in this function); did you mean 'DT_N_S_soc_S_peripheral_50000000_S_i2c_9000_S_kx132_1211_1f_ORD'?
   80 | #define DEVICE_NAME_GET(name) _CONCAT(__device_, name)
      |                                       ^~~~~~~~~
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/toolchain/common.h:124:26: note: in definition of macro '_DO_CONCAT'
  124 | #define _DO_CONCAT(x, y) x ## y
      |                          ^
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/device.h:80:31: note: in expansion of macro '_CONCAT'
   80 | #define DEVICE_NAME_GET(name) _CONCAT(__device_, name)
      |                               ^~~~~~~
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/device.h:257:37: note: in expansion of macro 'DEVICE_NAME_GET'
  257 | #define DEVICE_DT_NAME_GET(node_id) DEVICE_NAME_GET(Z_DEVICE_DT_DEV_NAME(node_id))
      |                                     ^~~~~~~~~~~~~~~
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/device.h:271:34: note: in expansion of macro 'DEVICE_DT_NAME_GET'
  271 | #define DEVICE_DT_GET(node_id) (&DEVICE_DT_NAME_GET(node_id))
      |                                  ^~~~~~~~~~~~~~~~~~
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo/src/main.c:95:25: note: in expansion of macro 'DEVICE_DT_GET'
   95 |     dev_accelerometer = DEVICE_DT_GET(DT_NODELABEL(KX132_1211)); // (kionix_sensor));
      |                         ^~~~~~~~~~~~~
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/device.h:80:39: note: each undeclared identifier is reported only once for each function it appears in
   80 | #define DEVICE_NAME_GET(name) _CONCAT(__device_, name)
      |                                       ^~~~~~~~~
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/toolchain/common.h:124:26: note: in definition of macro '_DO_CONCAT'
  124 | #define _DO_CONCAT(x, y) x ## y
      |                          ^
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/device.h:80:31: note: in expansion of macro '_CONCAT'
   80 | #define DEVICE_NAME_GET(name) _CONCAT(__device_, name)
      |                               ^~~~~~~
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/device.h:257:37: note: in expansion of macro 'DEVICE_NAME_GET'
  257 | #define DEVICE_DT_NAME_GET(node_id) DEVICE_NAME_GET(Z_DEVICE_DT_DEV_NAME(node_id))
      |                                     ^~~~~~~~~~~~~~~
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/zephyr/include/device.h:271:34: note: in expansion of macro 'DEVICE_DT_NAME_GET'
  271 | #define DEVICE_DT_GET(node_id) (&DEVICE_DT_NAME_GET(node_id))
      |                                  ^~~~~~~~~~~~~~~~~~
/home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo/src/main.c:95:25: note: in expansion of macro 'DEVICE_DT_GET'
   95 |     dev_accelerometer = DEVICE_DT_GET(DT_NODELABEL(KX132_1211)); // (kionix_sensor));
      |                         ^~~~~~~~~~~~~
[34/177] Building C object zephyr/CMakeFiles/zephyr.dir/lib/os/bitarray.c.obj
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/bin/cmake --build /home/ted/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo/build

ted@localhost:~/projects/zephyr-based/z4-sandbox-kionix-work/kionix-driver-demo$

        Haven’t yet got my head wrapped around Device Tree and Zephyr macros system, but I notice there is a tracing of macros, and macro expansions. The build error “traces” of these pre-processor build steps seem to be repeated: there is the undefined symbol, and then a series of six macro definitions beginning with the “deepest” macro. These six expansions then repeat before the next error is listed, or compilation terminates altogether.

        Is there a more specific Zephyr documentation I can review to understand DEVICE_DT_GET macro better? I am mis-providing something which DEVICE_DT_GET needs to process. I will watch Marti Bolivar’s Zephyr and Device Tree video again. I recall him describe DEVICE_DT_GET as a newer feature in Zephyr. This macro only became available in Zephyr 2.5.0.

        A summary of how device tree overlay files, I think specifically device tree nodes and their key-value pairs map to Zephyr macros would be really helpful. The minus character in a couple of my first node labels turned out to be illegal in the eventually generated C code. (Only trying to spell out a part name as it appears in datasheets and app notes) Would be good to know which device tree node key-value pairs must have values whose spelling and naming convention strictly honors C variable and macro naming conventions.

        • Ted

          The Marti Bolivar video I mentioned just above in previous message to this post is at https://www.youtube.com/watch?v=sWaxQyIgEBY. Right around 00:25:30 Marti explains the difference between a device tree ‘node label’ and the label property of a node. And following this explanation he emphasizes that, para-quoting Marti:

          “. . . label property is old and busted. Node labels are the new hotness . . .”

          This section of “Deep Dive into Zephyr 2.5 Device Tree” is what prompted me to select my node label as the value / parameter I expressed in the line of code you corrected for me, top of this forum post. But perhaps I misunderstand Marti’s device tree explanation or how to correctly set up and utilize DEVICE_DT_GET.

          Update: got help and solved this problem. In the driver for Kionix KX132-1211 sensor I am working on, I had a mal-formed DT_DRV_COMPAT assignment. The importance of this device tree macro is emphasized in Jared Wolff’s Memfault blog post, https://interrupt.memfault.com/blog/building-drivers-on-zephyr. The section of the post gives the nxp_pcf85063a as an example DT_DRV_COMPAT value, with a small substitution of underscore character for comma. Quoting the programming need here from Jared’s post:

          This aligns with the compatible = "nxp,pcf85063a"; set in the Device Tree. (Replacing a , with _)

          Though I had read and noted this point a couple weeks ago, I still overlooked it when correcting some device tree labels and macros during a couple of restructure efforts I made to my early Zephyr driver works.

          Thank you Jared (and Nordic Devzone as well) for the help so far! Wanted update and close this particular question as solved. Will pay closer attention to these Device Tree requirements going forward!

          • Ted

            tedhavelka66 excelent! Yes that DT_DRV_COMPAT entry is tricky. It’s definitely screwed me up a few times. Glad you’ve resolved this!

              Terms and Conditions | Privacy Policy