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.

TM4C123GH6PM: Reading Hibernation RTC Sub Seconds (HIBRTCSS)

Part Number: TM4C123GH6PM

Hello,

Datasheet on page 522 states that:

The RTC value can be read
by first reading the HIBRTCC register, reading the RTCSSC field in the HIBRTCSS register, and
then rereading the HIBRTCC register. If the two values for HIBRTCC are equal, the read is valid.

Why is this? What happens to the subsecond register when hibrtcc is going +1?

I wrote two functions that I can use interexchangebly:

uint32_t get_rtc_posix_sub(void) {
    return (HibernateRTCGet() << 15) | (HWREG(HIB_RTCSS) & HIB_RTCSS_RTCSSC_M);
}

// notice: this recursive variant does it as stated in datasheet.
uint32_t get_rtc_posix_sub_formal(void) {
    uint32_t posixTime = HibernateRTCGet();
    uint32_t subseconds = (HWREG(HIB_RTCSS) & HIB_RTCSS_RTCSSC_M);
    if(posixTime==HiberNateRTCGet()) {
        return (posixTime << 15) | (HWREG(HIB_RTCSS) & HIB_RTCSS_RTCSSC_M);
    } else {
        return get_rtc_posix_sub_formal();
    }
}

Basically after getting my rtc to work, all i want is ability to timestamp things with posixTime + 15 bits subsecond. Since RTC provided does not have a calendar, it counts from 9 to 3600 x 24

So since this wont ever exceed 17bits, I shift the seconds counter by 15bit, and put the subsecond counter to this 15 bit blank to get a second + subsecond timestamp.

Any ideas greatly appreciated. Are there any previous  examples of work for similar purposes?

Best Regards,

C.

  • The RTC value can be read
    by first reading the HIBRTCC register, reading the RTCSSC field in the HIBRTCSS register, and
    then rereading the HIBRTCC register. If the two values for HIBRTCC are equal, the read is valid.

    Why is this? What happens to the subsecond register when hibrtcc is going +1?

    The reason is that HIBRTCC and HIBRTCSS are two different registers. HIBRTCC is at address offset 0x0 while HIBRTCSS register is at 0x28. To read the seconds and the sub-seconds of the RTC counter, it would take take the processor two different read operations by first reading the HIBRTCC register and then reading HIBRTCSS register. When reading the HIBRTCSS register, it is possible that HIBRTCC register has already incremented to the next count value. For example, let's say the RTC has a value that consists of HIBRTCC equal to 0x1234 and the HIBRTCSS equal to 0xFFFF. If CPU reads HIBRTCC, you would get 0x1234. Next you would read HIBRTCSS. This is where a problem could arise. By the time the CPU reads HIBRTCSS, it is possible that the sub-second has rolled over to 0 and the HIBRTCC becomes 0x1235. If you simply concatenate HIBRTCC and HIBRTCSS you would get 0x1234 for the second and 0x0 for the sub-second. This is obviously wrong compared to the expected value which is 0x1234 and 0xFFFF. This is why to re-read HIBRTCC register again. If the second read of HIBRTCC has a different value than the first read then you know there is a roll-over just happened.  

    The HIBRTCC register is set by writing the Hibernation RTC Load (HIBRTCLD) register. A write
    to the HIBRTCLD register clears the 15-bit sub-seconds counter field, RTCSSC, in the HIBRTCSS
    register. To ensure a valid read of the RTC value, the HIBRTCC register should be read first, followed
    by a read of the RTCSSC field in the HIBRTCSS register and then a re-read of the HIBRTCC register.
    If the two values for the HIBRTCC are equal, the read is valid. By following this procedure, errors
    in the application caused by the HIBRTCC register rolling over by a count of 1 during a read of the
    RTCSSC field are prevented.