Regarding OSAL clock system in Z-Stack

OSAL provides a function, osal_GetSystemClock(), that returns a 32-bit (unsigned) value that represents the number of milliseconds since the last device reset. ZStack does not provide for any other system time functions, such as conversion to date-time -- that is left up to the application developer.

This time counter is maintained for sleeping devices which are using HAL_SLEEP_TIMER (PM1 and PM2). Devices that use HAL_SLEEP_DEEP (PM3) turn off all H/W except capability to receive some external interrupts to wake up the CC2530. Take a look at the hal_sleep.c file for information relating to sleep.

I believe that the MSP430 varients have a compiler option to add in a real-time clock capability.

Hi,

How accurate is the time returned from this function?

Thanks,

Yiliang

The resolution of the OSAL system clock is 1 millisecond. Updates to this clock are derived from "...free running rollover count of the MAC backoff timer; this timer runs freely with a constant 320 usec interval. The count of 320-usec ticks is converted to msecs and used to update the OSAL clock and Timers by invoking osalClockUpdate() and  osalTimerUpdate()." This all happens from the call to osalTimeUpdate() in the OSAL task scheduler main loop (see the osal_start_system() function).

The answer to your question depends on at least three variables: (1) the accuracy of the crystal used to derive the interrupts to drive the 320 usec MAC timer, (2) the possibility of critical sections longer than 320 usec that cause missed MAC timer interrupts, (3) maximum length of time to complete a task called from the OSAL main loop. Assuming that (2) is not happening (very bad if it does), then long-term accuracy should be determined by (1).

Item (3) determines the latency of updating the OSAL clock to account for accumulated MAC timer ticks. For example, if a task takes 5 seconds to execute, the OSAL clock will be 5 seconds "behind" when the task completes and won't be updated until that task returns control to the OSAL main loop. This is typically not a problem since OSAL is not a pre-emptive scheduler so one task is not interrupted by another. In other words, the OSAL system clock gets updated before each task gets called from the OSAL main loop.

Hello, what will happen if the situation (2), critical sections longer than 320 usec that cause missed MAC timer interrupts

I find some bugs in our system and I suspect that could be due to this (In timer allocation, because I saw sometimes timer allocation fails). so is there any one can help me to figure out what is the consequence  if one MAC timer INT is missed

thanks

Rui Zhang

Does this timer ever overflows and do we have information when this happens? If it overflows, does it start counting from zero to max value again?

I need to measure elapsed time when button is pressed.

So, my intention is:

when button is pressed:

uint32 pTime = osal_GetSystemClock();

when button is released:

uint32 rTime = osal_GetSystemClock();

uint32 elapsedTime = rTime - pTime;      

This way, sometimes for elapsedTime I got to big value and it looks like to me as overflow situation

Any Ideas?

Best regards

Yes, the counter rolls over to zero and continues counting upwards from there.

To handle that event when calculating elapsed time, you could use something like:

elapsedTime = ( rtime >= ptime ) ? ( rtime - ptime) : (4294967296ul - ( ptime - rtime ));