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.

CC2340R5: CC2340R5 RTC

Part Number: CC2340R5

Hi,

We have a requirement for mainting RTC time on the CC2340R5. 

We will receive the epoch time in seconds via UART. During our overall system's sleep state we wish to have RTC to be running. 

From what I see from the TRM, we have two registers "TIME524M" and "TIME8U" which has counter that increments the register at 0.5s and 8us respectively.

One approach is to read the registers and use them for time keeping. Alternatively we also see that there is a "CH0CC8U " register which can be used to generate a compare event once the desried value is set.

  1. How do I generate an interrupt to wake up the system from standby using the RTC compare event, where do I register for a callback?
  2. Could you also suggest how effectively "TIME524M" and "TIME8U" can be used to maintain time keeping.

 I tried looking for example but I haven't found any so far. I have also confirmed that RTC is the only peripheral/module that remains active during sleep state so any other alternatives will not work for our use case as we are in sleep state.

 

  • Hello Sandeep Singh,

    It should be possible to use the compare event plus RTC to wake the device up, if you want to peruse this route I would recommend looking at the driver functions that control sleep as this is what they basically do low level (code wise). 

    However if you want a quick solution to achieve the same result I would recommend using the sleep functions (sleep, usleep, ClockP_sleep, ClockP_usleep). In this specific case you would first create a variable to hold the value of your device's RTC, then find the "delta" you need to sleep for (by taking the current RTC value vs future), once that delta is found you load that into your sleep function to sleep until the  time expiries and you wake up. You can then use another variable to generally keep track of the time, and if needed save this into the NVS region to save data for later use. 

    Thanks,
    Alex F

  • Hi Alex,

    It should be possible to use the compare event plus RTC to wake the device up, if you want to peruse this route I would recommend looking at the driver functions that control sleep as this is what they basically do low level (code wise).

    Where should I look for this? I don't see folders/files that contain info regarding the RTC. 

    However if you want a quick solution to achieve the same result I would recommend using the sleep functions (sleep, usleep, ClockP_sleep, ClockP_usleep). In this specific case you would first create a variable to hold the value of your device's RTC, then find the "delta" you need to sleep for (by taking the current RTC value vs future), once that delta is found you load that into your sleep function to sleep until the  time expiries and you wake up. You can then use another variable to generally keep track of the time, and if needed save this into the NVS region to save data for later use. 

    While this is a decent alternative, There are two problems here.

    1. In standby mode the ClockP functions do not work and cannot be woken used to wake from standby.

    2.  If I use ClockP_usleep then the entire system goes to sleep and other operations such as BLE, UART etc are blocked. 

    My goal is to do the below:

    I have already received the Unix time in seconds, I can update the "CH0CC8U " to generate an interrupt after 10 seconds. Once I get a compare event then it means that 10 seconds have elapsed and I can update the UNIX time by 10 seconds. This way my BLE and other activities do not get blocked and we need not worry if the device is in active state or standby since RTC is powered in both the domains.

    Kindly guide me how I can effectively use the "CH0CC8U" register and the compare event.

    The " ISET Register" talks about settings interrupts, Once we set an interrupt where can we get the callback for it? and how do we register for it?

    Thanks,

    Sandeep

  • Hello Sandeep,

    Kindly guide me how I can effectively use the "CH0CC8U" register and the compare event.

    Here is some code of the powercc23x0.c driver that has some "similar" code to what you are trying to do:

        /* Switch CPUIRQ16 in event fabric to RTC.
         * Since the CC23X0 only has limited interrupt lines, we need to switch the
         * interrupt line from SysTimer to RTC in the event fabric.
         * The triggered interrupt will wake up the device with interrupts disabled.
         * We can consume that interrupt event without vectoring to the ISR and then
         * change the event fabric signal back to the SysTimer.
         * Thus, there is no need to swap out the actual interrupt function of the
         * clockHwi.
         */
        EVTSVTConfigureEvent(EVTSVT_SUB_CPUIRQ16, EVTSVT_PUB_AON_RTC_COMB);
    
        /* Clear interrupt in case it triggered since we disabled interrupts */
        HwiP_clearInterrupt(INT_CPUIRQ16);
    
        soonestDelta = nextEventTimeUs - HWREG(SYSTIM_BASE + SYSTIM_O_TIME1U);
    
        /* Get current time in 8us resolution. Must be done as close as possible to
         * getting the SysTimer time above.
         */
        rtcCurrTime = HWREG(RTC_BASE + RTC_O_TIME8U);
    
        /* Ensure the device wakes up early enough to reinitialise the
         * HW and take care of housekeeping.
         */
        soonestDelta -= PowerCC23X0_WAKEDELAYSTANDBY;
    
        /* Convert delta to RTC units */
        soonestDelta /= RTC_TO_SYSTIMER_TICKS;
    
        /* RTC channel 0 compare is automatically armed upon writing the
         * compare value. It will automatically be disarmed when it
         * triggers.
         */
        HWREG(RTC_BASE + RTC_O_CH0CC8U) = rtcCurrTime + soonestDelta;
    
        /* Go to standby mode */
        result = Power_sleep(PowerLPF3_STANDBY);

    Thanks,
    Alex F

  • Hi Alex, 

    Since the CH0CC8U is being used by the BLE stack as well. I don't think think modifying it is a good idea. There is a chance that the value can be overwritten.

    Thank you for this update.

    I will currently got ahead using the TIME524 as a time reference and build my logic around it. 

    Thanks 

    Sandeep