• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 52 subscribers
  • Views 179 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2642R: Issue with Util_xxxClock not being consistent.

Greg Lantz
Prodigy 20 points
Part Number: CC2642R

I am developing an application on the ble dev board with an external program sending current time via uart to the 2642 at a 10 second interval.  I am using the clock utilities to update the time every 10 milliseconds.  

The application is based on the simple_broadcaster example.  The BLE advertisement contains the current time.  Over 12-14 hours the timer has slowed to around 15 milliseconds.  The code to set up the clock is:

Util_constructClock(&clkAdvUpdate, SimpleBroadcaster_clockHandler,
SB_ADV_UPDATE_TIMEOUT, SB_ADV_UPDATE_TIMEOUT,
true, SB_UPDATE_ADV_EVT);

#define SB_ADV_UPDATE_TIMEOUT                10

The clock handler:

static void SimpleBroadcaster_clockHandler(UArg arg)
{
uint8_t evtId = (uint8_t) (arg & 0xFF);

switch (evtId)
    {
          case SB_UPDATE_ADV_EVT:
                   SimpleBroadcaster_enqueueMsg(SB_UPDATE_ADV_EVT, 0);
                   Util_startClock(&clkAdvUpdate);
          break;

         default:
         break;
    }
}

I'm outputting a signal I can track with an oscilloscope and see that the time interval grows over time to well over 50% error.  

This error only occurs when I am receiving the uart message every 10 seconds with the time.  If I don't send the message, the timer stays at 10 milliseconds.

Any ideas?

I am using sdk 5-10-00-48.

  • 0
    Guru 86745 points

    Hi,

    What is the source of your clock value? If you have a RTC clock running as source, then you should compare this value to the received broadcast message. The broadcast message occurs at an interval.

    -kel

  • +1
    TI__Guru**** 216767 points

    Hi Greg,

    One usage error in the code snippet you've provided is that since SB_ADV_UPDATE_TIMEOUT is provided as the clockDuration and clockPeriod, it is not necessary to call Util_startClock during every SB_UPDATE_ADV_EVT since it should be operating periodically and was not established as a one-time clock.  You should either use SB_ADV_UPDATE_TIMEOUT as the clockDuration (one-shot operation) or call Util_startClock once outside the context of SimpleBroadcaster_clockHandler (periodic operation).  For more information about TI-RTOS Clocks, please reference the BLE5-Stack User's Guide.  Unless you are defining POWER_SAVING for standby operation, using a 16-bit hardware timer channel or the sensor controller is an advisable approach to offload the main MCU and increase accuracy.  The RTC-based Util Clock is not expected to be called so frequently during operation.,

    What code executes when the UART message is received every 10 seconds?  Please provide code snippets of your UART initialization, callback, etc.  As you've noted that the issue only occurs when this is implemented, it would seem that the RTC is accurate but the additional application code could delay the Util resources from running, resulting in the drift you are experiencing.  Optimizing the existing code or replacing clock resource will likely resolve the issue.  I also ask that you would reference the Debugging Guide to further explore options while continuing the investigation of this matter.

    Regards,
    Ryan