BUG in RTC code ???

Hi Andre,

Your observations are correct. As RTC clocks at 32768Hz, meaning 1 sec is equal to 32768 clock ticks.

Ideal way of getting time in millisecond will involve floating point arithmetic (division by 32.768). To avoid this, we simply divide it by 32, which will give a range from 0 -1023(instead of 0-999). To use this output correctly we have to take care of this inaccuracy externally.

refer to the rtc_hal.c for more clarity:

#define U16MS_CYCLES(msec)	((msec *1024)/1000)
#define CYCLES_U16MS(cycles)	((cycles *1000)/ 1024)
.
.
static void rtc_value_rd(struct u64_time *value)
{
        u16 msec_cycles = 0;
        
        MAP_PRCMRTCGet(&value->secs, &msec_cycles);
        .
        .
        value->nsec = U16MS_U32NS(CYCLES_U16MS(msec_cycles));
}

vice versa, we need to take care  while setting value for alarm.

static inline void rtc_alarm_wr(const struct u64_time *alarm)
{
        MAP_PRCMRTCMatchSet(alarm->secs,
        U16MS_CYCLES(U32NS_U16MS(alarm->nsec)));
}

I hope this answers your question.

we'll add this information as comments for the concerned APIs.

let me know if you need any more clarification.

Thanks and Regards,
Rahul

Hi Kumar,

Yes the feedback did explain the problem, unfortunately to get a proper solution required a significant change in the logic of how we track live uptime with a 1mS accuracy

Will mark as answered...

Andre