This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RTOS/CC2640R2F: RTOS/CC2640R2F

Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2640, SYSBIOS

Tool/software: TI-RTOS

Hi,

In my application, I want to use the RTC in cc2640r2f and the logic is very simple.

get timestamp periodically by using 

ISeconds_Time ts;

Seconds_getTime(&ts);

and update/set the timestamp when needed by using, 

Seconds_set(newTime);

But the issue is that the RTC clock lost after any reboot triggered by either OAD or Watchdog, meaning I have to re-sync timestamp again. Since the battery is always connected to the board and no power loss, is there a way to let the timestamp/RTC continue? 

Thank you,

  • Hi David,

    Are you able to reproduce the issue on a unmodified OAD project where the RTC is reset after an OAD reboot?

    You should only need to call Seconds_set() when you are receiving a time sync from an external time source such as NTP or a user manually keying in the time on your device. Otherwise, you should be able use Seconds_getTime() through a reset.

    Additionally, for your information both watchdog timeouts and OAD resets will trigger a system reset with cause SYSRESET. This is because warm resets (what the watchdog triggers) are mapped to emulated pin resets by the boot code.

  • Hi Sean,

    First of all, thank you very much for your reply.

    Second of all, below is how I reproduced the RTC reset issue after an OAD reboot.
    1. Import the simple_peripheral_cc2640r2lp_oad_offchip examples including bim, stack and app from simplelink_cc2640r2_sdk_1_50_00_58.
    2. make a minor change in order to get/set RTC through a command line by using gatttool. The diff is attached below.
    3. build and load the simple_peripheral_cc2640r2lp_oad_offchip_app_FlashROM_oad_merged.bin and bim_oad_offchip_cc2640r2lp_app.hex to LaunchPad CC2640R2F
    4. connect to the lp by using the command below and do the reset of the test.

    4.1 connect to lp,
    $ gatttool -b B0:91:22:69:F6:E8 -I
    [B0:91:22:69:F6:E8][LE]> connect
    Connection successful

    4.2 show handlers
    [B0:91:22:69:F6:E8][LE]> char-desc
    ... ...
    handle: 0x0021, uuid: 0000fff1-0000-1000-8000-00805f9b34fb
    ... ...
    handle: 0x0027, uuid: 0000fff3-0000-1000-8000-00805f9b34fb
    ... ...

    4.3 get the current timestamp from RTC, and showing it is increasing every second,
    [B0:91:22:69:F6:E8][LE]> char-read-hnd 0x0021
    Characteristic value/descriptor: 87 43 6d 38
    [B0:91:22:69:F6:E8][LE]> char-read-hnd 0x0021
    Characteristic value/descriptor: 88 43 6d 38

    4.4 change the timestamp to a different value, and showing the timestamp keep increasing every second after the change
    [B0:91:22:69:F6:E8][LE]> char-write-cmd 0x0021 00112233
    [B0:91:22:69:F6:E8][LE]> char-read-hnd 0x0021
    Characteristic value/descriptor: 01 11 22 33
    [B0:91:22:69:F6:E8][LE]> char-read-hnd 0x0021
    Characteristic value/descriptor: 02 11 22 33
    [B0:91:22:69:F6:E8][LE]> char-read-hnd 0x0021
    Characteristic value/descriptor: 03 11 22 33
    [B0:91:22:69:F6:E8][LE]> char-read-hnd 0x0021
    Characteristic value/descriptor: 04 11 22 33
    ... ...
    4.5 simulate the OAD reboot by calling the HAL_SYSTEM_RESET();
    [B0:91:22:69:F6:E8][LE]> char-write-cmd 0x0027 11
    [B0:91:22:69:F6:E8][LE]>
    (gatttool:2738): GLib-WARNING **: Invalid file descriptor.

    4.6 reconnect back after a reboot,
    [B0:91:22:69:F6:E8][LE]> connect
    Attempting to connect to B0:91:22:69:F6:E8
    Connection successful

    4.7 check the timestamp from RTC, and found the timestamp reset.
    [B0:91:22:69:F6:E8][LE]> char-read-hnd 0x0021
    Characteristic value/descriptor: 84 43 6d 38
    [B0:91:22:69:F6:E8][LE]> char-read-hnd 0x0021
    Characteristic value/descriptor: 86 43 6d 38

    The LaunchPad is powered on during the entire testing. Please let me know how I can make the RTC work properly.

    Thanks in advance,
    David

    ======= Below is the diff from the original simple_peripheral_cc2640r2lp_oad_offchip example =======
    $ diff cc2640_r2_csdk.cfg cc2640_r2_csdk-after.cfg
    160c160,161
    <
    ---
    > var Seconds = xdc.useModule('ti.sysbios.hal.Seconds');
    >
    $ diff simple_gatt_profile.c simple_gatt_profile-after.c
    58a59,61
    > #include <ti/sysbios/hal/Seconds.h>
    > #include <ti/sysbios/interfaces/ISeconds.h>
    > #include "hal_mcu.h"
    613,614c616,623
    < *pLen = 1;
    < pValue[0] = *pAttr->pValue;
    ---
    > *pLen = 4;
    > // pValue[0] = *pAttr->pValue;
    > uint32_t sec;
    > ISeconds_Time ts;
    > Seconds_getTime(&ts);
    > sec = ts.secs + 946684800;
    > VOID memcpy( pValue, &sec, 4 );
    >
    668d676
    < case SIMPLEPROFILE_CHAR3_UUID:
    674c682,683
    < if ( len != 1 )
    ---
    > // if ( len != 1 )
    > if ( len != 4 )
    687,697c696,709
    < uint8 *pCurValue = (uint8 *)pAttr->pValue;
    < *pCurValue = pValue[0];
    <
    < if( pAttr->pValue == &simpleProfileChar1 )
    < {
    < notifyApp = SIMPLEPROFILE_CHAR1;
    < }
    < else
    < {
    < notifyApp = SIMPLEPROFILE_CHAR3;
    < }
    ---
    > // uint8 *pCurValue = (uint8 *)pAttr->pValue;
    > // *pCurValue = pValue[0];
    > //
    > // if( pAttr->pValue == &simpleProfileChar1 )
    > // {
    > // notifyApp = SIMPLEPROFILE_CHAR1;
    > // }
    > // else
    > // {
    > // notifyApp = SIMPLEPROFILE_CHAR3;
    > // }
    > uint32_t newTime;
    > memcpy( &newTime, pValue, 4 );
    > Seconds_set(newTime - 946684800); //sec between Jan 1st, 1970-2000
    700a713,716
    > case SIMPLEPROFILE_CHAR3_UUID:
    > HAL_SYSTEM_RESET();
    >
    > break;
  • Hi David,

    I have confirmed with our hardware team that this is in fact expected behavior.

    The AON (including RTC) domain will be reset during a system reset in order to ensure that all power domains are in the proper state when bringing up the device. 

    Given your use case I can recommend the following

    1. For the highest precision/reliability, an external RTC could be used

    2. Your device could re-sync with a known Time provider such as BT peer with Time Service or NTP

    3. If you know you are about to reboot, you could attempt to store the current RTC value and then retrieve it after reboot (adding to it the time to boot) and use that calculated value in your Seconds_set call. However, this would require a lot of profiling of your system and is the least recommend approach as it is inherently inexact.

  • Hi Sean,

    Thank you very much for helping on this RTC issue.

    We successfully workaround the RTC issue by following the your third suggestion, and more over, we also be able to address some other exceptions by storing timestamp in external flash combined with the on-chip watchdog. 

    After a few weeks testing, we totally satisfy the solution on RTC, however, we found an other interesting issue which triggers reboot and we can't capture it by using watchdog. I have posted this issue at,   if you can take a look and give us some workaround suggestions, then our product should be ready for roll-out soon.

    Thanks in advance, 

    David