Closed beiszhihao closed 2 years ago
Hi there @beiszhihao ! Thanks for the detailed report. I need to confirm 2 things with you.
#define DT_DRV_COMPAT micro_wm89xx
In the same file you are using DT_INST_FOREACH_STATUS_OKAY
? You must define DT_DRV_COMPAT
for this to work.
Please see this documentation for details and examples for how to use DT_INST_FOREACH_STATUS_OKAY
: https://docs.zephyrproject.org/latest/guides/dts/howtos.html#option-1-create-devices-using-instance-numbers
"micro,wm89xx"
compatible? See here for more information about bindings: https://docs.zephyrproject.org/latest/guides/dts/bindings.html#dt-bindingsHi @mbolivar-nordic Thank you for your reply
I make sure I'm using DT_ INST_ FOREACH_ STATUS_ OKAY
source code file declares DT_DRV_COMPAT
and ensure that it is associated with drivertree
I used DT_ NUM_ INST_ STATUS_ OKAY
#if DT_NUM_INST_STATUS_OKAY(DT_DRV_COMPAT) == 0
#error"WM89xx series coder is not defined in DTS"
#endif
I saw this happen in a different scenario happens with power domain. In the follow example you have a domain and two devices using it. The DT will generate aa dependency between them, but the domain may not be defined if we don't build with this feature enabled. In this situation the same problem will happen, we will have an undefined reference ...
/ {
test_domain: test_domain {
compatible = "power-domain";
status = "okay";
};
test_dev_a: test_dev_a {
compatible = "test-device-pm";
status = "okay";
power-domain = <&test_domain>;
};
test_dev_b: test_dev_b {
compatible = "test-device-pm";
status = "okay";
power-domain = <&test_domain>;
};
};
So, if I understood correctly, we can't have a device "depending" on other that is not defined, even if this dependency is optional.
@beiszhihao I know you have given me a detailed report, but I think there may be some missing piece of information. If you are still having problems, could you please provide a git branch that reproduces the issue, along with a west build
command that shows how it happens? The undefined reference to __device...
is a generic problem that happens if you try to get a device pointer from a devicetree node if no such device exists. The underlying infrastructure is well tested so I suspect there is a misconfiguration in the driver itself.
hi @mbolivar-nordic I am having this exact same problem. I have created a repo here which just implements a simple fake accelerometer sensor driver, if you just clone and then west build
(board is set inside the CMakeLists.txt
file) you will see the error:
src/main.c:30: undefined reference to
__device_dts_ord_3'`
I am unsure if the cause is related, but if you could point me in the right direction for how to debug these DTS binding issues it would be greatly appreciated.
I have solved my error. There was a spelling mistake in the DRV_COMPAT declaration for my custom driver (although to be fair, this isn't exactly a helpful error message for someone who doesn't deeply understand the zephyr build system)
No issue with this, but for whoever finding this issue from a search engine, here is the Zephyr documentation about it: https://docs.zephyrproject.org/latest/build/dts/troubleshooting.html Thanks!
Thanks for your input!
I had a similar problem after using the example-application as a blueprint for my own project. However the issue I found was that in the file <your_repository_with_west.yml>/zephyr/module.yml
(see example) the line dts_root: .
was previously commented by me. Uncommenting it probably made the
Describe the bug Hi zephyr developers, Hello!
I recently developed a wm89xx coder driver for a development board. My example is drivertree. The registration code is as follows:
But I had a problem compiling:
Remind me undefined reference to `__device_dts_ord_92',I studied it carefully. The problem lies in this registration macro
So I went to check the implementation of this macro in the zephyr source code and tried to get some useful information from it
Through the above definition and description, I probably understand_ device dts ord 92, of which 92 is the ID of the device in the tree, so I think this function is an automatically generated function, so theoretically it should be automatically generated by the zephyr construction tool, but I don't know why this function is not generated for my driver project, so I checked zephyr map
My function is not imported into the map, so I'm sure the builder didn't generate this for me _ device dts ord function I checked the definition in the DTS file again. Because this coder is used as a slave device of I2C, I declared it under I2C
I think there should be no problem with the above DTS definition So I went back to zephyr
DEVICE_DT_INST_DEFINE
the stage of define source code, I found that it calledDEVICE_ DT_ DEFINE
, so I went to check its source code again Finally, I located this macro function, which is the final registration driven macroFrom the analysis of the source code, I know that
Z_DEVICE_ DEFINE_ P
registers driver functions such as power management and usesCOND_ CODE_ 1
to determine whether the driver has passed in the power function pointer,Z_DECL_ALIGN
For segment alignment It was this macro that finally caught my attentionThrough its macro description, I see such a description:
I noticed this
with its devicetree ordinal, and provides the dependency ordinals.
AndZ_DEVICE_DEFINE
:Like DEVICE_DEFINE but takes a node_id AND a dev_name, and trailing dependency handles that come from outside devicetree.
Therefore, I think it needs some associations. My device is declared under the I2C DTS, including some I2C device codes used in my driver. Therefore, I think it is necessary to set some options to enable I2C support, but thestatus
in the DTS has been written as"Okay"
, so I refer to some compiled examples in samples I refer to the example ofsensor/bme280
. I find that there is a kconf in this exampleI began to try it. I found that when I set
config I2C
to N, the same problem as me will appear, which surprised me very much, because this problem has made progress. When I set I2C to y in my driver kconfig, my project was surprisingly compiled and passed, and there will be no previous problems. So I guess the reason isZ_DEVICE_DEFINE
The macro define gets the properties of the dependent device node, where it usesCOND_ CODE_ 1
this macro performs conditional compilation. If the dependent node function has no driver, zephyr will not compile the I2C device. If the dependent device driver has not been compiled, zephyr will not generate it__ device_ dts_ ord
functionIn order to further verify my conjecture, my
Prj.conf
in the app project Add config toCONF_I2C=y
, it is found that the effect is the same as that inkconfig
, so my conclusion is basically determined. The above is my debugging process and solution to this problem. When this problem occurred, I tried to search for information on the Internet and found that someone also encountered this problem, but there was no solution,So I think it is necessary to submit this question to the issueBest Regards, Stephen Zhou