I encounter an "undefined reference to `__device_dts_ord_152'" error when attempting to incorporate the peripheral_uart demo code into my customized application. Can you please assist me in resolving this issue?

I'm encountering difficulties while integrating the logic from the peripheral_uart into my customized application. To showcase the problem, I've created a brief video available at this link: https://youtube.com/live/h0GjFsJRF_0

It appears that I may have overlooked certain configurations within the .prj file, KConfig, or device tree. I would greatly appreciate your assistance in troubleshooting this issue.

Parents
  • Neat video!

    I have seen a lot of videos that are less than helpful, but this one actually really helped, and I also like your channel. Looking forward to seeing more of it!

    Just to answer the question at the end of the video, while I remember it:

    nordic_nus_uart: NUS is short for Nordic UART Service, which is a Bluetooth Service that we have used a lot for quite some time. It is a simple Bluetooth Low Energy service simulating a wireless UART connection. It doesn't actually need to use a physical UART (but the sample does so by default). It is simply a "tunnel" that can send data strings in both directions. 

    Now: nordic_nus_uart -> Nordic NUS UART -> Nordic Nordic UART Service UART. It is just a naming thing, and not a very good one, I might add. It just means "the uart instance that we will use for our NUS BLE service. So basically, a hook to one of the UART instances on the DK.

    I downloaded your project, and built it in v2.4.0. (You are probably using NCS v2.3.0 or earlier, since v2.4.0 was released yesterday, but since it builds just fine* in v2.4.0, I recommend using that, and you will include a couple of bugfixes as well). 

    *builds just fine, meaning it doesn't throw any other errors than the one you are seeing, undefined reference to __device_dts_ord_...

    When I built, I got an undefined reference to device_dts_ord_153, not 152, but I am not sure if that is because we are building on different computers, or if I used v2.4.0 and you did not. However, this message in itself doesn't tell me much, other than dts (device tree structure) is missing something. These numbers are not static, so to see which one it refers to, you need to look in your build folder.

    (I just recently learned this, so it is not really that intuitive).

    Check the file found in:

    build\zephyr\include\generated\devicetree_generated.h

    In my case, 153 refers to usbd@36000/cdc_acm_uart1. Is that the case for your 152 as well?

    You should know that it is possible to use the USB peripheral instead of the UART as an input/output in this application, but I believe you are trying to use the actual UART. 

    Both your main.c and prj.conf are looking good. The reason the peripheral_uart sample builds, while your doesn't is due to a kind of complex build system. In the peripheral_uart folder, there is a file called app.overlay. You have this file in your application folder as well, but since you also have a file in boards\nrf5340dk_nrf5340_cpuapp.overlay, this is chosen by default, overriding the app.overlay. 

    When building your project, I can see from close to the top of the build log:

    -- Found devicetree overlay: C:/Nordic_Semiconductor/SDKs/ncs/my_projects/2.4.0/test/nrf5340DroneCode-master/boards/nrf5340dk_nrf5340_cpuapp.overlay

    While if you build the peripheral_uart sample, you will see:

    -- Found devicetree overlay: c:/Nordic_Semiconductor/SDKs/ncs/my_projects/2.4.0/bluetooth/peripheral_uart/app.overlay

    It is possible to override the automatic selection of these by using the additional CMake command "-DDTC_OVERLAY_FILE=app.overlay" when creating your build configuration:

    But I don't think you want to do this, because it looks like you have already set a lot of settings here, so you probably want to keep using your nrf5340dk_nrf5340_cpuapp.overlay file (removing it gives other build errors). 

    So to build your application, you need to change line 34 in your boards\nrf5340dk_nrf5340_cpuapp.overlay from:
    nordic,nus-uart = &cdc_acm_uart1;
    to:
    nordic,nus-uart = &uart0;

    And it should build, using the UART as expected.

    Best regards,

    Edvin

  • I appreciate your response greatly. It's quite amusing that you mentioned substituting it with uart0, as I actually went ahead and did that, which allowed it to compile successfully. However, despite this change, the BLE initialization and advertising still fail to work. The specific error message I encounter is -5.

    In addition to the uart0 replacement, I've taken a few other steps. Firstly, I updated the SDK to version 2.4, for which I thank you for providing the information. Furthermore, I've created a video to showcase and demonstrate the current issue I'm facing. You can find the video at the following link: https://www.youtube.com/live/hx9JIXuMfqc?feature=share

  • Hello,

    I didn't actually try to run the sample. I just compiled it. Just checking by the tickets, but I am at home now, and I don't have any nRF5340 DKs available here. I can look into it on Monday. 

    What function is it that returns -5? bt_enable() or adv_start()?

    Oh, and I realized I can just watch your video. Here we go.

    FYI: If it doesn't detect the DK, you can hover over the "Connected devices" tab in the bottom left, and a refresh button will appear:

    Alternatively, if anything else hangs, you can press ctrl + shift + p, and type "reload window", hit enter, and it will restart all the plugins for you. I use it if the navigation stops working from time to time. 

    The reason the logger doesn't work is because of this part in your prj.conf:

    # Config logger
    CONFIG_LOG=y
    CONFIG_USE_SEGGER_RTT=y
    CONFIG_LOG_BACKEND_RTT=y
    CONFIG_LOG_BACKEND_UART=n
    CONFIG_LOG_PRINTK=n

    It will not work to log over UART, because the UART is controlled by your application. Hence, the log module is set to use the RTT backend. You can monitor it using either a separate RTT terminal, such as Segger RTT Viewer, and you probably have it installed if you have NCS and VS Code up and running. 

    The setup should look something like this:

    Note that you need to reconnect to the device every time you re-flash the firmware. This is because of the nature of how RTT works. In Segger's RTT viewer, just hit F2 and enter, and it will re-load the log buffers.

    Alternatively, you can use the RTT viewer in nRF Connect for VS Code:

    This also needs to be re-connected on every re-flash.

    I tried dissecting your application, removing all the PWM, I2C, SPI etc, in order to only test the BLE part of it without having to write an nRF52840dk overlay file, but when I did so, everything worked well (advertising, that is). I will have to test it on an nRF5340DK on Monday. Would it be possible to (unless you did it already) upload the latest application you are using on Github?

    And just to be sure, what version of the DK are you using? I couldn't tell from your video. It should say e.g. 2.0.0 on a big white sticker close to the programmer USB port on the DK. Just so that I can test it on the same version that you are using.

    Best regards,

    Edvin

  • Thank you for responding quickly. To tackle the issue, I've been working on it by using the peripheral_uart example. My plan is to integrate the pwm, spi, and i2c drivers into it. Up until now, I have successfully implemented the bi-directional BLE and 4-channel PWM. I will soon work on incorporating the spi and i2c drivers. I will update you on my progress and share the code on GitHub.

Reply Children
Related