Good evening Jared,
Thank you for the fast reply! These syntax examples both work in a limited way, that is, I can compile these lines themselves. But soon as I refer to the
const struct device *sensor = DEVICE_DT_GET(DT_NODELABEL(stmicro_sensor_addr_18)) or
= DEVICE_DT_GET(DT_INST(1, st_iis2dh));, I get a link time error:
/opt/zephyr-sdk-0.12.4/arm-zephyr-eabi/bin/../lib/gcc/arm-zephyr-eabi/10.2.0/../../../../arm-zephyr-eabi/bin/ld: app/libapp.a(thread-iis2dh.c.obj): in functioniis2dh_thread_entry_point’:
/home/ted/projects/zephyr-based/sandbox/stage1-firmware-aws-iot-mqtt-client/src/thread-iis2dh.c:1230: undefined reference to
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Strange thing here is that source code line 1230 is about one hundred eighty lines beyond the reference, and not related to a Zephyr device object pointer in any way. I get this same link time error for each pairing of device tree macros above. I also tried making the node label string shorter, but same result.
Though the custom board I’m bringing up is work related, so that I cannot share much detail of the hardware, it employs the nRF9160 for many of the same uses as are present in the Sparkfun_Thing_Plus_nrf9160 board. I’m working with sensors on the third of four i2c peripherals. GPIOs have changed in their assignments, but I’m pretty sure Nordic’s 9160 SiP Cortex-M33 supports i2c2 clock and data lines to be map-able to any of the general purpose GPIOs on P0.
In the custom board’s “primary” device tree file, whcih I named [custom_board_name]_common.dts to match the convention in Zephyr and Nordic supported boards, I’ve made sure that pins I assign to SCL and SDA of my one active I2C peripheral are not assigned to any other devices. I also made sure to enable this peripheral with:
status = "okay";
Device Tree Source paradigm gets converted into C code sometime early during project build, but it’s not clear to me where an intermediate C source file generated by
dts compiler lives. If I knew this, I could compare such a source-file-as-build-artifact between the working Sparkfun board project and the new project branch for a custom board.
Is there another configuration step I have or may be missing here, checking to see that I’ve properly configured and enabled the I2C bus on which these sensors reside?