CC2530: osal_systemClock timer offset issue

Thanks Yikai Chen,

Is there any particular reason for clock drift ?

What you are proposing is a work around solution considering that clock drift will always be there.

I was going through the forum and did not find more posts on this topic, and did not find many posts on clock drift. So I assume its a rare event of occurrence.

Hi Suhrith,

All external crystals have some amount of drift, and although the maximum allowed tolerance limit for proper CC2530 operation is +/-40 PPM this can also vary based on board design and environment.  You can refer to SWRA372 for recommendations.  Thus as YK suggested, time synchronization with an outside source is the optimal way to maintain a consistent reference.

Regards,
Ryan

Thanks Ryan,

I acknowledge the solution proposed by you and YK.

As per your first statement I understand that the drift will be of very small magnitude (which should be negligible), but can the offset/ drift happen by 90 minutes (5400 seconds) instantaneously within a short duration due to any case ?

And also this happens occasionally/ randomly for every node, I just want to eliminate any software involvement in this issue.

How long do you run to get 90 minutes drift? I would suggest you to do print time passed by a periodic time event to check how much time drift actually happens over time.

We have observed this when mostly nodes have been running over 30 days, we are running several tests along with the one proposed by you to get exact specifications of the issue. Will update when we get a clear result.

For the time being I can explain the issue with a hypothetical situation:

Lets consider node is powered on 1st June at 12:00 AM, then continuously running until 5th July 12:00 AM. 

On 5th July at 12:00 AM, I expect the osal_system_clock when read should return ( 35 days X 24 Hours X 3600 seconds x 1000 milliseconds = 3024000000 milliseconds)

at 12:05 AM on 5th July,  the osal_system_clock jumps ahead by 90 minutes instantaneously - this is the issue i.e. ( 3024000000 milliseconds + ( 90 + 5 mins x 60000 milliseconds) =  3,02,97,00,000 milliseconds) 

When I read osal_system_clock value at 12:10 AM, the reading will now be 3,03,00,00,000 instead of 3,02,46,00,000 (approx equal to 54,00,000 milliseconds = 90 minutes)

This is to explain that the offset/drift is not accumulated over time it happens instantly

How are you obtaining values from the OSAL system clock inside your project (I assume osal_GetSystemClock or osal_getClock)?  Are you able to recreate the issue quickly or mitigate it through osal_setClock manipulation?  Please provide code snippets if possible.  

Regards,
Ryan

We are using osal_GetSystemClock 

Trying to recreate issue quickly to provide more insights. Will check possibility to mitigate it through osal_setclock manipulation.

The code snippet of read attribute in ReadWriteAttrCB

case ATTR_UPTIME:

{

switch( oper )

{

case ZCL_OPER_READ: {

uint32 temp = osal_GetSystemClock();

osal_memcpy(pValue,&temp,4); }

case ZCL_OPER_LEN:

*pLen = 4;

break;

default:

break;

}

}

It may also be useful to investigate whether the value of temp is ever incorrectly copied to pValue.

Regards,
Ryan

osal_GetSystemClock has been used in other parts of the application for computation and calculation , and we have noticed that osal_GetSystemClock value  gets affected due to the issue everywhere

Hence we can rule out incorrect copy to pValue

Regards,

Suhrith

I suggest you to create a periodic timer event to print the result of osal_GetSystemClock() to trace what happens over time in your CC2530.

Hi, I from same team and working on same project as Suhrith, just to clarify and update on the issue we are facing.

In short here’s what our code is doing.

• One reload timer TIMER_R for every 5 minutes. Let’s call this event as HEARTBEAT_EVENT
• HEARTBEAT_EVENT will send elapsed time in seconds from osal_GetSystemClock()/1000 - someConstant.
• We are not manipulating the osal clock anywhere in the code.

Here issue we are facing.

• Most of the time is works (like 99%), i.e., it sends correct values every after 5 mins. ie every HEARTBEAT_EVENT
• But rarely it sends jumped value of exactly around 90 minutes (instead of showing increment 300s it shows increment of approx. 5485s)
• Because this jump happens it affects heartbeat time and also one more long timer (up to 24 Hours timer), it also jumps by 90 minutes and event got triggered 90 minutes earlier.

Here’s what our logs looks like

12-07 16:18:25  Heartbeat from node 0xXYZ time=3129
12-07 16:23:25  Heartbeat from node 0xXYZ time=3429
12-07 16:25:43  Heartbeat from node 0xXYZ time=8914

• Here you can see that from 16:18 to 16:23, difference is exact 5 mins as expected. And also, time value is also correct.
• But after that you can see heartbeat event got occurred 2 mins before, i.e., it should be at 16:28:25 (16:23:25 - 16:28:25 = 300s) but it occurred at 16:25:43-16:23:25 = 138s, and also time value jumped by 8914-3429 = 5485s = 91m.

Which Z-Stack version do you use and see such issue?

Hi Akash,

Please print the raw values of osal_GetSystemClock during this time so that we may understand whether an overflow issue is involved.  It would also be helpful if you confirmed this issue with a default Z-Stack example using TI EVMs.  You can also submit your hardware to SIMPLELINK-2-4GHZ-DESIGN-REVIEWS for further review.  Given the declining support of Legacy CC253X Z-Stack solutions in favor of the SIMPLELINK-CC13XX-CC26XX-SDK, I recommend that you mitigate the issue by catching it in your application (i.e. compare against the last saved value) and consider using a CC26X2XX variant in future products.

Regards,
Ryan