CC2652R7: set RTC value

Hi,

Thank you for reaching out. I apologize that you were unable to resolve your question in the previous thread. Based on your description, my guess is that the BLE5-Stack is levering the RTC peripheral and modifying it unexpectedly may be causing unintended behavior. Taking a step back, could you describe what you are attempting to implement on your side? It may be possible to do it using the clock drivers or timer drivers which leverage the RTC in the backend.

Best Regards,

Jan

As I understand it, the RTC module does not save its value after power is turned off, so when it is turned on, it starts counting from 0. When starting the entire system, I want to change the value of the SEC register so that it points to my current real time in UNIX. Therefore, I am trying to write the required value to this register.

Hi Nick,

Got it. Thank you for the explanation. Can you share how you are trying to perform the register write? A code snippet would be helpful. I can use it to discuss with R&D how we should try to modify this register during runtime properly.

Best Regards,

Jan

It happens as simply as possible
I have a task with the RF part that broadcasts the device (GapAdvEnable) and there is a task for the console (shell), through which commands entered from the keyboard are processed. When I enter the time change command, the second task simply calls writing directly to the RTC register.

HWREG(AON_RTC_BASE + AON_RTC_O_SEC) = sec; 

I have tried to perform various combinations of code invocation

for example, like this

AONRTCDisable();
HWREG(AON_RTC_BASE + AON_RTC_O_SEC) = sec;
AONRTCEnable();

HWREG(AON_RTC_BASE + AON_RTC_O_SEC) = sec;
HWREG(AON_RTC_BASE + AON_RTC_O_CH0CMP) = ((sec+5)&0xFFFF)<<16;

I tried to call one of these functions from osal after changing RTC_SEC, since obviously something from the rf part changes the CH0CMP registers, but I don't understand the logic yet and how to do it correctly

osalAdjustTimer(1);
osalTimeUpdate();
osalTimerUpdate( sec +1 );
osal_timer_refTimeUpdate();
osal_next_timeout();                
TimerP_dynamicStub(0);

Hi,

Got it. Thank you for the additional details. I have reached out to R&D and I hope to hear back from them early next week. Have you had a chance to test the alternative mention you are mentioning and verified it works?

Best Regards,

Jan

Hi

I tried to run the clock via utc_block.c and it seems to work fine.
But I haven't investigated enough how this module calculates the time after sleep mode. I'll try to clarify it in the same way next week.
But I think it's still a priority for me to change the RTC register directly

Hi Nick,

Understood, I have already reached out to the R&D experts and I am awaiting their response. I hope to hear back from them early in the week. In the meantime, if you have any additional findings, then please share them in this thread and I will take a look & share them with R&D if it may be helpful.

Best Regards,

Jan

Okay, thanks
I will be waiting for a response from your experts.

Hi,

Okay, I tried to do something like this

__STATIC_INLINE void hal_rtc_sec_set_2(unsigned int sec)
{
    AONRTCDisable();
    uint32_t diff = HWREG(AON_RTC_BASE + AON_RTC_O_CH0CMP) - HWREG(AON_RTC_BASE + AON_RTC_O_TIME);
    HWREG(AON_RTC_BASE + AON_RTC_O_SEC) = sec;
    HWREG(AON_RTC_BASE + AON_RTC_O_CH0CMP) = diff + (uint32_t)((sec&0xFFFF)<<16);
    AONRTCEnable();
}

Unfortunately, this changes the registers as expected, but it still negatively affects the operation of the BLE stack.
When changing the RTC registers, I still observe that something inside the RF breaks. I think there are some counters in the variables inside that give the wrong result due to the fact that I changed the RTC register and the reality does not meet expectations

I think one of the possible reasons lies inside the ClockP_workFuncDynamic function.

there is a variable "distance" where the result of the function ClockP_walkQueueDynamic is written.
Due to the change of values ​​in RTC, I think that incorrect mathematical calculations are performed inside this function and because of this, incorrect timings are set. As a result, the entire BLE stack stops working correctly.
I still haven't figured out how exactly this can be bypassed, even if it is a magic trick.
Do your experts have any advice? Can they repeat the experiment when the device is working and broadcasting on the air, and at that moment we change the RTC value?

Hi,

Got it. I got some information from our BLE R&D specifically and it is not recommended to set or reset the RTC while RF stacks are active as they heavily rely on the RTC. They recommend using a reference variable instead.

Best Regards,

Jan

Hi,

Can your team give advice on how to suspend the Rf stack, change the RTC register and then restart the RF stack so that it recalculates the time intervals and works correctly?
Or do you confirm that everything inside the RF stack is directly related to the RTC values and any impact directly on the RTC can lead to incorrect operation?

Hi,

To suspend the RF stack when using BLE, you will need to cease all connections and stop all scanning & advertising. Afterwards, it may be possible for it to modify the RTC register as mentioned in the pseudocode. However, doing so while any RF operation is ongoing will likely lead to incorrect behavior as you have seen.

Best Regards,

Jan

Hi
OK, thanks for the help.
I have no questions at the moment, thanks for the help.