Zephyr RTC build issue.

Greetings,

 In the process of adding the RTC driver to the project I am encountering a build error when I try to setup a device pointer. The offending line is:

 const struct device *rtc_ptr = DEVICE_DT_GET(DT_NODELABEL(rtc0));

In prj.conf I have added:

CONFIG_RTC=y
CONFIG_NRFX_RTC0=y
CONFIG_COUNTER=y
The build error message is:

C:/ncs/v2.9.0/zephyr/include/zephyr/device.h:92:41: error: '__device_dts_ord_82' undeclared here (not in a function); did you mean '__device_dts_ord_2'?

   92 | #define DEVICE_NAME_GET(dev_id) _CONCAT(__device_, dev_id)

It appears that the device driver is not being compiled based on this error message. I am using V2.9.0 of the Zephyr SDK and building on a Windows PC with VS Code.

The configuration board target is nrf52dk/nrf52832

Are additional Kconfig options required to be enabled?

I am able to compile calls to RTC functions that don't require the device pointer such as:

rtc_time_to_tm( struct rtc_time *);

Thanks for any help with this issue!,

Best regards,

Mark

   

Parents Reply Children
  • Greetings and thanks for the additional input!

     Initially I tried changing the nrf52dk_nrf52832.overlay file which gave me the same build error. Revisiting the l3_e2 tutorial; I used the DeviceTree Visual Editor and under SOC I could see that the rtc0/1/2 were not enabled. after enabling rtc0 it updated app.overlay file at the same level as the /src directory. This added:

    &rtc0 {
    status = "okay";
    };

     After that I am able to build successfully and setup the device pointer as follows: 

    const struct device *rtc_ptr = DEVICE_DT_GET(DT_NODELABEL(rtc0));
    I would have expected the overlay file in /boards to have the same effect, evidently the app.overlay file takes precedence.
     Thanks much for your help with this issue!
    Best regards,
    Mark   
  • Hi, 

    I wanted to clarify — were you actually able to use any Zephyr RTC API functions (like rtc_get_time() or rtc_set_time()) with that rtc_ptr, or did the code just compile successfully only?

    Just wanted to confirm if the RTC hardware is functionally working under Zephyr’s RTC API, or if it’s just a build-time symbol resolution fix.

    Thanks,




  • Greetings,

    Thanks for following up! I have had limited success using the RTC APIs. I created 2 rtc_time structs:

     // 2:15:10, August 20, 2025, Wed, 232nd day, DST = unknown, nanosecs = 0 (unknown)

    struct rtc_time Set_clock_time = {10, 15, 2, 20, 8, 125, 3, 232, -1, 0};

    struct rtc_time Get_clock_time = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};

    Calling int Set_TM_ret = rtc_set_time(rtc_ptr, &Set_clock_time); returns success (0) and appears to start the RTC. I can see the NRF_RTC_Type* regs->COUNTER value increasing at the 32.768 kHz clock rate. 

    Calling int Get_TM_ret = rtc_get_time(rtc_ptr, &Get_clock_time); returns success (0) however the Get_Clock_time struct is not changed - any thoughts on why that might be happening?

    For our application we would like to set the pre-scaler to 1 mS (value = 32). It seems that I have to stop the RTC to set the pre-scaler -> regs->TASKS_STOP = RTC_TASKS_STOP_TASKS_STOP_Trigger 

    After that I can see the counter advancing at the 1 mS rate. When I do this it appears to cause issues with the radio. The peripheral is advertising OK and connects briefly and then disconnects. I captured a trace using the Bluetooth Low Energy App and it is showing this repeatedly:

    00> [00:06:05.920,959] <wrn> bt_conn: conn 0x20002488 failed to establish. RF noise?

    00> [00:06:05.921,447] <inf> HnB_NUS_module: Disconnected: 73:36:87:1F:7A:91 (random), reason 0x3e

    Taking out the RTC init the peripheral is able to connect with the central and read device info OK. Any thoughts on how the RTC initialization could be affecting the radio?

     I am using rtc0 for my testing and we don't have a 32.768 kHz crystal on our PCB so in prj.conf, I am setting:

    CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y in prj.conf to force RC oscillator for LFCLK.

     I appreciate your feedback on these issues with the RTC on the NRF52832.

    Best Regards,

    Mark

Related