• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 40 subscribers
  • Views 772 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.

Help required to improve/replace the RTC functionality

Andre Maree
Intellectual 855 points

Hi TI staffers

I am in the process to replacing the (simulated) RTC functionality with something more accurate. I have already tested the logic and have improved the accuracy to be 100% accurate on 1mS intervals and within 2.53mS on 100Sec intervals.

The problem I now have is the delay incurred when updating the HIB3P3_O_MEM_HIB_REG2 and HIB3P3_O_MEM_HIB_REG3 using the DriverLib API functions.

For each read/write operation the PRCMHIBRegWrite() and PRCMHIBRegRead() it incurs a 200uSec or 600uSec in total. To update the time every milli second, a 600uSec delay is a very big penalty.

My questions are:

Q: What are the timing constraints around accessing the registers ?.

Q: How can the read and write operations be interleaved to minimise the delays?

I have searched the web as well as the TRM but have not been able to find any description around this timing issue.

Thanks

  • 0
    Intellectual 855 points
    I have found the vague section in the release notes #14 in SDK 1.0.0 so am now aware of "some" background. However, in order to try and move forward it would help to understand the exact restrictions in more detail.

    Q1: If I shadow the values of the HIB2/3 registers in SRAM and ONLY write it back to the registers, both in quick succession, will that be OK?

    Q2: If I choose to only track epoch seconds in SRAM and write that back to a single register every milli second (with no delay afterwards), will that be OK?

    Q3: If a HIB2/3 register is accessed as 8 bit or 16bit values, how does that affect timing rules?

    Q4: If HIB REG2 is used only for system flags and accessed in the bitmapped memory range, what rules/intervals should apply?

    Thanks
  • 0 in reply to Andre Maree
    TI__Genius 16085 points
    Hi Andre,


    We will look into this and get back to you.


    Regards,
    Aashish
  • 0 in reply to Aashish Bhanawat
    TI__Genius 16085 points

    Hi Andre,


    To access HIB3P3_O_MEM_HIB_REG2 and HIB3P3_O_MEM_HIB_REG3 registers you need PRCMHIBRegread/write() and delay cant be avoided as mentioned in release note "by virtue of their connection on the device bus matrix, require a much longer access cycle compared to all other registers in the MCU memory map. Uncontrolled back to back accesses mapping the above mentioned registers could interfere with the data path efficiency / stability of the device."


    You may use below faster interface for RTC:
    /* macro to pick two matching count values */
    #define COUNT_WITHIN_TRESHOLD(a, b, c, th) \
    ((((b) - (a)) <= (th)) ? (b) : (c))

    /*
    * get the current RTC count, using the fast interface; to use the
    * fast interface the count must be read three times, and then
    * the value that matches on at least two of the reads is chosen
    */
    for (i = 0; i < 3; i++) {
    count[i] = PRCMSlowClkCtrFastGet();
    }
    curr = COUNT_WITHIN_TRESHOLD(count[0], count[1], count[2], 1);


    But be aware of the below caveat :
    Due to the nature of implemetation of auto latching, when using this API, the recommendation is to read the value thrice and identify the right value (as 2 out the 3 read values will always be correct and with a max. of 1 LSB change.


    Regards,
    Aashish

  • 0 in reply to Aashish Bhanawat
    Intellectual 855 points
    Again, thanks for the feedback

    On reading the SCC, will write a function to implement the 3 read selection and return the best.

    On the HIB REG2/3 scenario I have implemented what I believe is a solution but would really like you comment on it. The logic is as follows:

    #1 I am using an SNTP client that initially sync network time to SRAM based Sec & mSec values.
    #2 I am using FreeRTOS with a 1 tick mSec interval to increment the mSec and (on roll over) the Sec values.
    #3 Every mSec tick I am simply doing a WRITE of the updated mSec value to HIB2, no delay other than the 1mS interval to the next WRITE.
    #4 On rollover (every second) I am doing a WRITE of the updated Sec value to HIB3, no delay other than the 1 mS interval to the next mSec write.
    #5 During the tick when the Sec update is done, I do NOT do the mSec update, so NOT doing 2 writes in succession.
    #6 I accept that for the 1 mS interval the time is out by 999 mSec, but the only solution would be to do the 1st WRITE with the 200uSec delay.

    No other writes or reads to/from the HIB REG2/3 take place other than on boot up, when the current values are read as initial seed for the SRAM based values..

    So far it seems to work very well. If there is anything I am missing, please let me know..

    André
  • 0 in reply to Andre Maree
    TI__Genius 16085 points

    Hi Andre,

    Above steps seems OK to us but need to test thoroughly. Also keep in mind that there should not be back-to-back access to HIB register, ensure min 200mSec delay between to call to access HIB register.

    Regards,

    Aashish