Missing device ord mapping when compiling drivers locally with nRF5340DK

Question

Hello,

Been chasing this undefined reference to `__device_dts_ord_XXX' issue around for awhile now with no clear path forward. What I am observing is extremely similar to this closed issue here:

https://github.com/zephyrproject-rtos/zephyr/issues/41677 which seems common with I2C slave devices. When there is a drivers\* directory local to the application, rather than inside of the ncs\2.0.0\zephyr\drivers\* directory

I recently have been getting myself acquainted with the nRF5340DK and have successfully compiled and flashed several of the examples provided by Nordic. I have moved into getting getting to know Zephyr more generally, and how to properly setup an environment for custom (local) driver development, which is what has led me to my present issue.

The footprint is there is no driver child nodes generated in the build\zephyr_pre0.map or build\zephyr_final.map that corresponds to the ord node found in in the build\zephyr.dts or build\include\devicetree_unfixed.h

It behaves as though the build is successful and generates correctly against the .yaml files in dts/bindings, but if you try to call

const struct device *dev = DEVICE_DT_GET_ANY(vendor_testdevice)

it will consistently fail for any device under the &i2c1 node with this undefined reference to `__device_dts_ord_XXX' since they exist in the devicetree.h but do not actually exist in the nRF5340 device mapping after compilation completes, even though I2C and TWIM1 are enabled in the prj.conf.

If this call is included, linking will fail. However, if it is excluded, linking will succeed -- making it particularly frustrating to troubleshoot why mappings are absent even though drivers are being successfully built.

In Zephyr's doumentation this was the closest result, https://docs.zephyrproject.org/latest/kernel/drivers/index.html which suggests "Check to make sure your device driver is being compiled, usually by enabling the Kconfig options it requires."

I can confirm it is being compiled, but I'm not quite sure why the mappings generate for the same driver (trying with BME280) when inside the ncs\2.0.0\zephyr\drivers\sensor\* but will not generate mappings when placed in a local <project>\drivers\sensor\* location with a corresponding <project>\dts\bindings\* and the respective Kconfigs and CMakeLists.txt

*(SORT_BY_NAME(SORT_BY_ALIGNMENT(.z_device_POST_KERNEL[1-9][0-9]_*)))

.z_device_POST_KERNEL50_

0x00000000000109e8 0x18 zephyr/drivers/i2c/libdrivers__i2c.a(i2c_nrfx_twim.c.obj)

0x00000000000109e8 __device_dts_ord_135

.z_device_POST_KERNEL50_

0x0000000000010a00 0x18 zephyr/drivers/mbox/libdrivers__mbox.a(mbox_nrfx_ipc.c.obj)

0x0000000000010a00 __device_dts_ord_21

.z_device_POST_KERNEL70_

0x0000000000010a18 0x18 zephyr/drivers/spi/libdrivers__spi.a(spi_nrfx_spim.c.obj)

0x0000000000010a18 __device_dts_ord_112

.z_device_POST_KERNEL90_

0x0000000000010a30 0x18 zephyr/drivers/sensor/bme280/libdrivers__sensor__bme280.a(bme280.c.obj)

0x0000000000010a30 __device_dts_ord_136

0x0000000000010a48 __device_APPLICATION_start = .

^ This is what is missing, so in this case I would get a

undefined reference to `__device_dts_ord_136' in the "local driver" built version.

Any suggestions of what else I can check?

bgx561 · Accepted Answer

Edvin, I appreciate the reply. I found the issue, and I'm hoping that posting here will same someone else a lot of pain troubleshooting their devicetree. 
 https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/application_development/out_of_tree_driver 
 I was not including my "vendor_testdevice" as a Zephyr module. 
 Pushing my entire project down a subdirectory into <project>\my_custom_module\drivers\* 
 and then including it as a module 
 
 list (APPEND ZEPHYR_EXTRA_MODULES 
 ${CMAKE_CURRENT_SOURCE_DIR} /my_custom_module 
 ) 
 
 fixes the issue I was seeing with the mapping not being generated and the build still being successful. 
 
 I tested this with an exact copy of the BME280 files to create a BME280TEST custom device and loaded it using the solution above, and was able to verify it gets mapped correctly in the build\zephyr_pre0.map and build\zephyr_final.map files. 
 
 ---

*( SORT_BY_NAME ( SORT_BY_ALIGNMENT ( .z_device_POST_KERNEL [ 1 - 9 ][ 0 - 9 ]_*))) 
 .z_device_POST_KERNEL50_ 
 0x000000000000c730 0x18 zephyr/drivers/i2c/libdrivers__i2c.a (i2c_nrfx_twim.c.obj) 
 0x000000000000c730 __device_dts_ord_135 
 .z_device_POST_KERNEL50_ 
 0x000000000000c748 0x18 zephyr/drivers/mbox/libdrivers__mbox.a (mbox_nrfx_ipc.c.obj) 
 0x000000000000c748 __device_dts_ord_21 
 .z_device_POST_KERNEL70_ 
 0x000000000000c760 0x18 zephyr/drivers/spi/libdrivers__spi.a (spi_nrfx_spim.c.obj) 
 0x000000000000c760 __device_dts_ord_112 
 .z_device_POST_KERNEL90_ 
 0x000000000000c778 0x18 zephyr/drivers/sensor/bme280/libdrivers__sensor__bme280.a(bme280.c.obj) 
 0x000000000000c778 __device_dts_ord_136 
 .z_device_POST_KERNEL90_ 
 0x000000000000c790 0x18 modules/my_custom_module/drivers/bme280test/lib..__..__..__dev__Documents__Nordic_Semiconductor__bgx561test__my_custom_module__drivers__bme280test.a(bme280test.c.obj) 
 0x000000000000c790 __device_dts_ord_137 
 0x000000000000c7a8 __device_APPLICATION_start = .

^Now both devices correctly show up in the device mapping.

Missing device ord mapping when compiling drivers locally with nRF5340DK

Top Replies