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.

CC1352P: Reading AON_RTC SEC and SUBSEC

Part Number: CC1352P


MCU is using 32768Hz (nominal) square wave signal to clock RTC.
I've also created a timer to read RTC every second. The question is, what are those 131072 tick jumps occurring every fifth read? Why subsec value is jumping? Or is it 48MHz xtal / HF clock?
See log below

read every sec
fieds: SEC, SUBSEC, prev_subsec-current_subsec, timer value when entering callback, timer value where AON_RTC:SEC was read in callback
t_iv is timer ticks previous_read - current_read

27 01960000 ss_iv=131072 t_iv=-3 000000ad 000000c5
28 01960000 ss_iv=-1 t_iv=3 000000b0 000000c8
29 01960000 ss_iv=-1 t_iv=2 000000b2 000000ca
2a 01960000 ss_iv=-1 t_iv=-6 000000ad 000000c5
2b 01960000 ss_iv=-1 t_iv=4 000000b1 000000c9
2c 01980000 ss_iv=131072 t_iv=-3 000000af 000000c7
2d 01980000 ss_iv=-1 t_iv=4 000000b3 000000cb
2e 01980000 ss_iv=-1 t_iv=-5 000000af 000000c7
2f 01980000 ss_iv=-1 t_iv=2 000000b1 000000c9
30 01980000 ss_iv=-1 t_iv=-3 000000af 000000c7
31 019a0000 ss_iv=131072 t_iv=-3 000000ad 000000c5
32 019a0000 ss_iv=-1 t_iv=4 000000b1 000000c9
33 019a0000 ss_iv=-1 t_iv=-1 000000b1 000000c9
34 019a0000 ss_iv=-1 t_iv=-1 000000b1 000000c9
35 019a0000 ss_iv=-1 t_iv=-3 000000af 000000c7
36 019c0000 ss_iv=131072 t_iv=-1 000000af 000000c7


read every 5 sec, now only those 131072 logged
41 01a20000 ss_iv=131072 t_iv=1 000000b2 000000ca
46 01a40000 ss_iv=131072 t_iv=-4 000000af 000000c7
4b 01a60000 ss_iv=131072 t_iv=3 000000b2 000000ca
50 01a80000 ss_iv=131072 t_iv=-1 000000b2 000000ca
55 01aa0000 ss_iv=131072 t_iv=-4 000000af 000000c7
5a 01ac0000 ss_iv=131072 t_iv=-1 000000af 000000c7
5f 01ae0000 ss_iv=131072 t_iv=2 000000b1 000000c9
64 01b00000 ss_iv=131072 t_iv=-3 000000af 000000c7
69 01b20000 ss_iv=131072 t_iv=1 000000b0 000000c8

read every sec, lf clock is using internal rc here, still there are those jumps
16 26ec0000 ss_iv=28573696 t_iv=-5 000000ad 000000c5
17 28a00000 ss_iv=28573696 t_iv=2 000000af 000000c7
18 2a540000 ss_iv=28573696 t_iv=-1 000000af 000000c7
19 2c080000 ss_iv=28573696 t_iv=-1 000000af 000000c7
1a 2dbe0000 ss_iv=28704768 t_iv=-1 000000af 000000c7 <<
1b 2f720000 ss_iv=28573696 t_iv=2 000000b1 000000c9
1c 31260000 ss_iv=28573696 t_iv=-1 000000b1 000000c9
1d 32da0000 ss_iv=28573696 t_iv=-3 000000af 000000c7


And here are interrupt inits and callback. Logs are printed in main loop.

void ppx_timeout(GPTimerCC26XX_Handle handle, GPTimerCC26XX_IntMask interruptMask)
{
  static uintptr_t key;
  static uint32_t s1;

  key = HwiP_disable();

  p_tv0 = HWREG(GPT2_BASE + GPT_O_TAV);

  do {
    p_sec = HWREG(AON_RTC_BASE + AON_RTC_O_SEC);
    p_tv1 = HWREG(GPT2_BASE + GPT_O_TAV);
    p_subsec = HWREG(AON_RTC_BASE + AON_RTC_O_SUBSEC);
    s1 = HWREG(AON_RTC_BASE + AON_RTC_O_SEC);
  } while(p_sec != s1);

  p_update = 1;

  HwiP_restore(key);
}

static void start_tmr_ppx()
{
  GPTimerCC26XX_Params ppx_params;

  GPTimerCC26XX_Params_init(&ppx_params);
  ppx_params.width          = GPT_CONFIG_32BIT;
  ppx_params.mode           = GPT_MODE_PERIODIC_UP; //GPT_MODE_PERIODIC_UP, GPT_MODE_ONESHOT_UP
  ppx_params.debugStallMode = GPTimerCC26XX_DEBUG_STALL_OFF;

  ppx_tmr = GPTimerCC26XX_open(CC1352R1_LAUNCHXL_GPTIMER2A, &ppx_params);

  GPTimerCC26XX_setLoadValue(ppx_tmr, 0x2DC6BFF); //1.0s

  GPTimerCC26XX_start(ppx_tmr);
}

  • Hi Aki,

    Which version of the SimpleLink SDK are you using?

    Cheers,

    Marie H

  • simplelink_cc13x2_26x2_sdk_4_20_00_35
    simplelink_cc13x2_26x2_sdk_4_40_04_04

  • Hi Aki,

    It looks like another driver might be using the RTC clock, overriding your settings.

    How are you outputting that 32768 Hz clock? Through PWM, or by outputting SCLK_LF directly using the CLK32KCTL register?

    Regards,

    Arthur

  • 32kHz clock signal is coming from external RTCC chip and that signal is driving CC1352's AON_RTC

  • My 32kHz clock is actually 32768.222Hz and if I change SUBSECINC to match that value 2^38/32768.222=0x7fffc7, then AON_RTC is giving these readings:

    SEC, SUBSEC, SUBSEC-prev_subsec
    399 02ddf062 ss_iv=-29185
    39a 02df7e61 ss_iv=101887
    39b 02df0c61 ss_iv=-29185
    39c 02de9a61 ss_iv=-29185
    39d 02de2861 ss_iv=-29185
    39e 02ddb661 ss_iv=-29185
    39f 02df4460 ss_iv=101887
    3a0 02ded260 ss_iv=-29185
    3a1 02de6060 ss_iv=-29185
    3a2 02ddee60 ss_iv=-29185

    Now subsec register lags behind, then does some "correction" jump, again every fifth second.

    I don't know if it's just a coincidence, but sum of those subsec intervals (101887+4*-29185) is -3.46us, which is -0.7ppm, pretty good.
    Compared to original (subsecinc 0x800000) sum is 30us (131072+4*0) per 5 seconds, which means 6ppm error which matches to 32768.222Hz (6.77ppm).

    But why subsec-register update is discontinuous?

  • Hi Aki,

    Chapter 16.2.2 of the CC1352 Technical Reference Manual (swcu185, page 1374) states that in order to access the SUBSEC register, which is what you are doing already. However, I feel like we are missing something.

    Have you tried using the Driverlib function library to control the RTC? https://dev.ti.com/tirex/explore/content/simplelink_cc13xx_cc26xx_sdk_6_40_00_13/docs/driverlib_cc13xx_cc26xx/cc13x2_cc26x2/driverlib/group__aonrtc__api.html

    If so, did you observe the same behavior?

    I am asking because Driverlib might have some additional handling to prevent that discontinuity.

    Also, are you using any other driver, such as the Power driver?

    Regards,

    Arthur

  • I modified timer callback to use AONRTCCurrent64BitValueGet(), no change

    void ppx_timeout(GPTimerCC26XX_Handle handle, GPTimerCC26XX_IntMask interruptMask)
    {
      static uintptr_t key;
    
      key = HwiP_disable();
    
      uint64_t rtc_time = AONRTCCurrent64BitValueGet();
      p_subsec = rtc_time;
      p_sec = rtc_time >> 32;
    
      p_update = 1;
    
      HwiP_restore(key);
    }

    Powerconfig is this

    const PowerCC26X2_Config PowerCC26X2_config = {
        .enablePolicy             = false,
        .policyInitFxn            = NULL,
        .policyFxn                = PowerCC26XX_standbyPolicy,
        .calibrateFxn             = PowerCC26XX_noCalibrate,
        .calibrateRCOSC_LF        = false,
        .calibrateRCOSC_HF        = false,
        .enableTCXOFxn            = NULL
    };

    Other drivers is use: rf, uart, gptimer, dma, aescbc, aecctr, trng, watchdog and pwm.
    NoRTOS, and application is never sleeping/idling, just a while loop polling and reacting to interrupt flags and calling state machines.
    Compiled using gcc-arm-none-eabi-9-2020-q2-update

  • RTC subsec gives discontinuous values also when reading from SCE using "sysGetRtcValue(output.rtcsec, output.rtcsubsec)".
    Read is done every 250ms using timer2+event, timer2 is clocked by xosc_hf

    6 a629
    6 e629 (diff 250msec exact for between two readings)
    7 2627 (here diff jumps by two ticks to 249.954 223 6 msec)
    7 6627 (and again exact 250ms)
    7 a627 (and here 250ms)
    7 e627 (same)
    8 2625 (here jump again, two ticks, 249.954 223 6 msec)
    8 6625 (250ms)
    8 a625 (250ms)
    8 e625 (250ms)
    9 2623 (249.954 223 6 msec)
    9 6623 (250ms)

    Any ideas what there is going on? Why subsec is jumping by two units? Where are e.g. subsec values 0xe628, 0x2626?
    This test was done on stock LAUNCHXL-CC1352P-2, using NoRtos/GCC/simplelink_cc13xx_cc26xx_sdk_6_40_00_13 uart2echo-example as base

  • Hi,

    are you familiar with this:

    By default, the AON_RTC increments its counter with 1/32768 seconds each 32-kHz clock tick. A
    subsecond increment value of 0x20 000 corresponds to 1/32768 seconds. Increasing or decreasing the
    subsecond increments value increases or decreases the speed of the AON_RTC by the same amount.

    Regards,

    Dimitar

  • Thanks, Dimitar

    So, while subsec register resolution is 0.2ns, it is updated only every 30.5us.
    If I read rtc at a moment t, then again t+20us (xosc_hf time) I may get the same value. I may also get value which is 30.5us larger, depending if 0x20000 edge occurs during 20us pause.

    20us pause between reads
    3d.ffd4c8f0 3d.ffd4c8f0 (same)
    3e.ffd2c8f0 3e.ffd4c8f0 (second value is increased by 0x20000/30.5us during 20us delay)
    3f.ffd2c8f0 3f.ffd4c8f0 (second value is increased by 0x20000/30.5us during 20us delay)
    40.ffd2c8f0 40.ffd2c8f0 (same)

    40us pause between reads, 0x20000 edge occurs definitely during that time, second value is always 0x20000 (30.5us) larger
    c.fffa2cec c.fffc2cec
    d.fff82cec d.fffc2cec
    e.fff82cec e.fffa2cec
    f.fff82cec f.fffa2cec

    That explains why my rtc reading intervals are jumping around

    2b1.fe04c8f0 iv=1.00000000
    2b2.fe02c8f0 iv=0.fffe0000
    2b3.fe02c8f0 iv=1.00000000
    2b4.fe00c8f0 iv=0.fffe0000
    2b5.fe00c8f0 iv=1.00000000

    or
    5cc.fedc9def iv=0.fffeafff (20us short)
    5cd.fedd4def iv=1.0000b000 (10us long)
    5ce.feddfdef iv=1.0000b000 (10us long)
    5cf.fedcaded iv=0.fffeaffe (20us short)
    5d0.fedd5ded iv=1.0000b000 (10us long)