iis2dh driver - I2C instance on bus okay "discovery" issue #51733
Replies: 4 comments
-
Hi @tedhavelka , I cloned your app https://github.com/tedhavelka/iis2dh-minimal into my v3.2.0 tree. I also modified iis2dh.h with these build warnings to see how this macro was evaluated at build time.
Here is my build output:
|
Beta Was this translation helpful? Give feedback.
-
Hi @tedhavelka ,
I hope you can find the issue on your end. Best regards |
Beta Was this translation helpful? Give feedback.
-
Hello @DerekSnell, Thank you for looking into my question on Zephyr's DT_ANY_INST_ON_BUS_STATUS_OKAY device tree macro. I believe I found the issue just several hours ago, in a misplaced During some code clean up I must have moved I was reminded of this requirement when searching for possible answers, and I found a reply from Marti Bolivar to another developer: Marti was speaking about the macro DT_INST_FOREACH_STATUS_OKAY. This macro however seems similar in some ways to the one I found in iis2dh.h, and I am guessing when I look up the definition of DT_ANY_INST_ON_BUS_STATUS_OKAY that it somewhere depends on DT_DRV_COMPAT expanding to some non-zero value. One thing that I am wondering, my issue first arose when both macro based tests failed silently in the building of
|
Beta Was this translation helpful? Give feedback.
-
Hi @tedhavelka ,
That sounds helpful to me. Best regards |
Beta Was this translation helpful? Give feedback.
-
Hello Zephyr Forum,
I am attempting to bring up a sensor interfacing module in a Zephyr based application, one which talks to an STMicro IIS2DH accelerometer. My target processor is NXP's LPC55S69, and the peripheral therein I am using for I2C is this microcontroller's flexcomm4 on chip serial peripheral. This peripheral is called out in device tree source files for the board lpcxpresso55s69, and associated microcontroller.
At build time I find that while Zephyr's device tree parsing proceeds without errors or apparent warnings, there's a conditional compilation of part of a data structure in iis2dh.h line 49. When the Zephyr toolchain, I'm assuming arm-none-eabi-gcc pre-processor reaches this in-tree source file, neither SPI nor I2C instances are ever found to have "okay" status. And yet I've called out not one but two sensors on the I2C bus of the target microcontroller.
What's more interesting, or strange to me, is that when I copy that DT_ macro from iis2dh.h line 49 into my application sources, there is tests true and returns '1'. I can toggle my app-side instance of
#if DT_ANY_INST_ON_BUS_STATUS_OKAY(i2c)
to return true or false, by commenting out and enabling corresponding DTS overlay lines for my I2C based sensors. But this pre-processor test always returns false during compiling of iis2dh.h.The reason this pre-processor test is important is that when it fails, the data structure for an instance of an iis2dh device as seen by Zephyr and driver routines lacks an 'i2c' data member. Without this there's no reference to the bus on which the sensor resides. For this the sensor is never found to be ready by calls to
device_is_ready()
.In the past year I have used STMicro's IIS2DH Zephyr driver code to successfully configure and talk to iis2dh accelerometers, in both Zephyr 2.6.0 and Zephyr 3.1.0. It is only with the latest migration to a newer Zephyr release that I've run into this issue, and have spent much of the past three days tracking down a root cause, and searching documentation and forums along the way for answers and sanity checks.
I've created something of a minimal Zephyr app to showcase this issue. It is based on Zephyr 3.2.0 samples/basic/blinky project, with some additions mostly to prj.conf Kconfig settings, and to the lone source file src/main.c. This project I've recently pushed to github.com at https://github.com/tedhavelka/iis2dh-minimal.
Is it normal that DT_ANY_INST_ON_BUS_STATUS_OKAY(i2c) would evaluate to 'false' as compilation processes Zephyr driver sources, and during the same build it may evaluate to 'true' in application source code? Or are there mistakes I've made in the sample app to showcase this "instance on bus" evaluation behavior?
I'm guessing there is one or more dumb errors I am making, but any insight or help the development community can offer I apprecate!
Beta Was this translation helpful? Give feedback.
All reactions