Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

Level 3
Level 3
25 sign-ins 10 replies posted 5 replies posted

We are working with a CYBT-423028-02 dual mode Bluetooth BR/EDR + BLE module. Because of a measurement timestamping requirement, I started to investigate use of the real-time clock (RTC) available in the CYW20719. Since the RTC would be reset by an external device each time it connects, high accuracy over the long term is not required. However, my results so far make the RTC unusable for our purposes.

I've included captured WICED_BT_TRACE messages generated by my program which is just the hello_client demo program with RTC functions added.

I added the following lines near the end of the hello_client_app_init() function:

    rtcConfig.oscillatorFrequencykHz= RTC_REF_CLOCK_SRC_32KHZ;


    rtcRefTime.year = 2019;

    rtcRefTime.month = 10;

    rtcRefTime.day = 20;

    rtcRefTime.hour = 6;

    rtcRefTime.minute = 0;

    rtcRefTime.second = 0;


When I call rtc_getRTCTime() immediately afterwards, it yields the expected time 06:00:00. After a RTOS delay of 60000 ms, a call to rtc_getRTCTime() yields a time of 06:01:04, an error of over +6%.

I also added a call to rtc_getRTCTime() in the 1-second app timer implemented in the hello_client demo program. After an actual elapsed time of 4m51s (as measured by my computer clock), the RTC shows an elapsed time of 5m12s, an error of over +7%. This seems quite high.

But, when a central device connects to the CYW20719, the RTC seems to increase its tick rate by a factor of 5.2 as shown by the RTC times in the trace messages. Worse yet, after the central device disconnects, the RTC appears to stop and continues to report the time at which the disconnection occurred.

Is an external crystal required for the RTC to work properly or am I missing something?

Here are my WICED_BT_TRACE messages. The timestamps in square brackets were generated by my COM port monitor program.

[14:17:18 ---] hello_client_management_cback: 15

hello_client_management_cback: 0


wiced_bt_gatt_register status 0

wiced_bt_gatt_db_init 0

called rtc_init()

[14:17:20 ---] called rtc_setRTCTime()

rtcTime@00 = 06:00:00

DELAY HERE: wiced_rtos_delay_milliseconds(60000, ALLOW_THREAD_TO_SLEEP);

[14:18:20 ---] rtcTime@60 = 06:01:04

[14:18:27 ---] rtcTime = 06:01:12

[14:18:35 ---] rtcTime = 06:01:21


[14:21:55 ---] rtcTime = 06:04:55

[14:22:03 ---] rtcTime = 06:05:04

[14:22:11 ---] rtcTime = 06:05:12

[14:22:16 ---] hello_client_gatt_callback event 0

hclient_connection_up Conn Id:1 Num conn:1,Addr:<00 a0 50 d9 18 85 > role:1

rtcConnectTime = 06:05:18

[14:22:19 ---] rtcTime = 06:05:34

[14:22:27 ---] rtcTime = 06:06:16

[14:22:35 ---] rtcTime = 06:06:58


[14:23:39 ---] rtcTime = 06:12:35

[14:23:47 ---] rtcTime = 06:13:17

[14:23:56 ---] rtcTime = 06:14:00

[14:23:59 ---] hello_client_gatt_callback event 0

hello_client_connection_down 1 <00 a0 50 d9 18 85 >

rtcDisconnectTime = 06:14:20

[14:24:04 ---] rtcTime = 06:14:20

[14:24:12 ---] rtcTime = 06:14:20

[14:24:20 ---] rtcTime = 06:14:20

1 Solution

Sorry for my mistake. The internal LPO has high drift rate. If you need to achieve sleep or idle function, the external 32k crystal is a must in your design.

View solution in original post

3 Replies
500 solutions authored 250 sign-ins 1000 replies posted

The internal LPO is inaccurate. If you want to get an accurate RTC, you need to use the external 32k crystal.



I assume that you meant to say that the internal LPO is inaccurate. I can accept that, even a 7% error would be understandable. However, if it is normal to have a 400% error while a connection is active and normal to have the RTC just stop running after a disconnect, it seems that the RTC should be documented as only usable with an external crystal rather than imply that the RTC is just less accurate when using an internal LPO.


Sorry for my mistake. The internal LPO has high drift rate. If you need to achieve sleep or idle function, the external 32k crystal is a must in your design.