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: Discrepancies in description of RTC Trim in datasheets

Part Number: TM4C123GH6PM
Other Parts Discussed in Thread: TM4C1294NCPDT, TM4C129ENCPDT

The DS-TM4C123GH6PM-15842.2741 SPMS376E datasheet dated June 12, 2014 contains the following description of RTC Trim in section 7.3.5.3:

The discrepancies between the operation of RTC Trim in the datasheet and an actual TM4C123GH6PM rev B1 part are:

1) In the case when the match interrupt is configured with RTCM0=0x1 and RTCSSM=0x7FFD the device gets only one match interrupt, rather than the two match interrupts suggested by the datasheet.

The output from the test program created to investigate the behaviour of RTC Trim:

6) Test match for sub-seconds of 0x7FFD, along with a trim value of 0x8002.
The trim value causes the sub-seconds to go backwards, such that according to the datasheet the
the match interrupt should occur twice. However, only one match interrupt occurs.
Since a RTC trim is applied which causes the time to go backwards two discontinuities are reported.
Tested RTC with HIBRTCM0=0x2c1 HIBRTCSS=0x7ffd HIBRTCT=0x8002
HIB#02 workaround : Yes  Reset RTC time on first match interrupt : No
Num RTC match interrupts=1
   RTC match interrupt around times (0x2c1,0x7ff9) (0x2c1,0x7ffa) (0x2c1,0x7ffb) (0x2c1,0x7ffc) (0x2c1,0x7ffd) *interrupt* (0x2c1,0x7ffe)
Num RTC time discontinuities=2
   RTC time discontinuity (0x2c0,0x7fff) -> (0x2c1,0x7ffd)
   RTC time discontinuity (0x2c1,0x7fff) -> (0x2c1,0x0)

The test program reported that it only received one match interrupt. The program enables RTC match interrupt, and polls the RTC time to detect:

- The RTC time at which a match interrupt occurs.

- If there is a discrepancy such that the RTC time doesn't change by advancing by one sub-second increment at a time.

A TM4C1294NCPDT rev A1 and TM4C129ENCPDT rev A2 behave in the same way as the TM4C123GH6PM rev B1.

2) In the case of TRIM Value of 0x7FFC the actual behaviour is as follows (based upon an edit of figure 7-6 in the datasheet to show the counter goes forwards rather than backwards):

The output from the test program for this test case was:

9) Test match for sub-seconds of 0x3, along with a trim value of 0x7FFC.
The trim value causes the sub-seconds to advance, such that a RTC match interrupt is seen.
Since a RTC trim is applied which makes the time go forwards one discontinuity is reported.
Tested RTC with HIBRTCM0=0x2c1 HIBRTCSS=0x3 HIBRTCT=0x7ffc
HIB#02 workaround : Yes  Reset RTC time on first match interrupt : No
Num RTC match interrupts=1
   RTC match interrupt around times (0x2c0,0x7ffc) (0x2c0,0x7ffd) (0x2c0,0x7ffe) (0x2c0,0x7fff) (0x2c1,0x3) *interrupt* (0x2c1,0x4)
Num RTC time discontinuities=1
   RTC time discontinuity (0x2c0,0x7fff) -> (0x2c1,0x3)

A TM4C1294NCPDT rev A1 and TM4C129ENCPDT rev A2 behave in the same way as the TM4C123GH6PM rev B1.

Are there errors in the datasheet description of the RTC trim?

For reference the test program used is attached, which was developed using CCS 7.2 and TivaWare 2.1.4.178. The program also demonstrates that TM4C123 devices can be affected by errata HIB#01 and HIB#02 unless the errata are worked-around in software. TM4C129 devices don't suffer from those errata.

TM4C_RTC_trim_overflow.zip

  •  *** LIKE ***  

    So thoughtful of "big brother" to force this (extra effort) upon (already) overworked "outside helpers!"   (for unspecified reasons...)

    Others here - and myself - are interested in what motivated this thorough (and much appreciated) detailed investigation.

    Thanks for your effort.     (although it is wondered if the "Next Forum (Upgrade?)" will prohibit such helpful postings - which are not in direct answer to the, "overly weighted requests" of those "new/confused.")

  • cb1_mobile said:
    Others here - and myself - are interested in what motivated this thorough (and much appreciated) detailed investigation.

    It was an attempt to understand the effect of the Hiberation RTC errata on a user application, since the investigation into TM4C123GE6PM: TM4C123gxl deep sleep mode issue showed that TM4C123 errata HIB#01 was causing the device to miss the RTC match and thus the device failed to wake up.

    The results\TM4C123GH6PM_rev_B1.txt file in the .zip file attached to the first post also illustrates the effect TM4C123 errata HIB#01:

    3) Test match for sub-seconds of zero:
    - Without HIB#01 workaround; since an undefined RTC trim is in use
    - With HIB#02 workaround
    This will result in no match interrupt and one discontinuity when the
    least 6 significant bits of the RTC seconds change from 0 to 1.
    Tested RTC with HIBRTCM0=0x2c1 HIBRTCSS=0x0 HIBRTCT=0x2040
    HIB#02 workaround : Yes  Reset RTC time on first match interrupt : No
    Num RTC match interrupts=0
    Num RTC time discontinuities=1
       RTC time discontinuity (0x2c0,0x7fff) -> (0x2c1,0x5fbf)

    And the effect of TM4C123 errata HIB#02:

    1) Test match for sub-seconds of zero:
    - Without HIB#01 workaround; since an undefined RTC trim is in use
    - Without HIB#02 workaround
    This will result in no match interrupt and multiple discontinuities
    due to the sub-seconds appearing to update non-monotonically.
    Tested RTC with HIBRTCM0=0x2c1 HIBRTCSS=0x0 HIBRTCT=0x2040
    HIB#02 workaround : No  Reset RTC time on first match interrupt : No
    Num RTC match interrupts=0
    Num RTC time discontinuities=41
       RTC time discontinuity (0x2c0,0x1abb) -> (0x2c0,0x1abf)
       RTC time discontinuity (0x2c0,0x1abf) -> (0x2c0,0x1abc)
       RTC time discontinuity (0x2c0,0x2b55) -> (0x2c0,0x2b57)
       RTC time discontinuity (0x2c0,0x2b57) -> (0x2c0,0x2b56)
       RTC time discontinuity (0x2c0,0x38bd) -> (0x2c0,0x38bf)
       RTC time discontinuity (0x2c0,0x38bf) -> (0x2c0,0x38be)
       RTC time discontinuity (0x2c0,0x423f) -> (0x2c0,0x427f)
       RTC time discontinuity (0x2c0,0x427f) -> (0x2c0,0x4240)
       RTC time discontinuity (0x2c0,0x4a8b) -> (0x2c0,0x4a8d)
       RTC time discontinuity (0x2c0,0x4a8d) -> (0x2c0,0x4a8c)
       ...

    I also realised that as of TivaWare™ Peripheral Driver Library USER’S GUIDE SPMU298E supplied with TivaWare 2.1.4.178 there is no mention of device errata, and no suggestions on the steps in using TivaWare to avoid the application from being impacted by device errata. That means that unless the users of TivaWare realise that the device errata must be checked, the application could be impacted by device errata.

    Given that TivaWare is promoted as something that avoids the user from having to read and understand the device datasheets and errata, perhaps the TivaWare user's guide could be updated to have some mention of how to avoid known errata from impacting the application.

  • *** LIKE ***     *** LIKE ***    *** LIKE ***    (Note: the "self-claimed" Forum Upgrade(?) (now) enables the bestowing of "Multiple LIKEs" - yet raises/speeds, "wear/tear & carpal-tunnel incidence" - upon hapless yet responsible posters - seeking to (properly) highlight & reward, "Post Excellence!'

    Past question of poster Chester by cb1: "What motivated so thorough - and superbly presented - an investigation?

    Chester Gillon said:
    It was an attempt to understand the effect of the Hiberation RTC errata on a user application

    Indeed a valiant effort - yet leads to the follow up question(s):

    • Why this particular - errata based - issue?      Indeed - there are "many" errata listings!      (Had you planned upon using Hibernate?    Or - might you be "systematically working your way thru" the "mass of MCU errata?) 
    • I cannot quite tell if this, "Test Match for Sub-Seconds errata" causes the failure to "awaken from Hibernate?"     Or - less impacting - simply yields a "timing error?"    Might you clarify?

    Chester Gillon said:
    TivaWare™ Peripheral Driver Library USER’S GUIDE (cb1 edit: Many/most such guides!) there is no mention of device errata

    Absolutely true - well identified & stated.    We user/specifiers do NOT "expect perfection" - yet we should have the expectation of,  "well publicized/noted & EFFECTIVE Warning!"   It proves insufficient to "lump all such warnings" into an adjunct,  "Single Listing Document!"   (i.e. "errata" - especially when simply "finding" the pertinent errata document proves a challenge.    It is noted that "no such discovery issue impacts, (vendor hallowed) "Blogs, Groups & TI Training!"     Despite repeated requests - "Pertinent Tech Documents for THIS FORUM'S MCU" somehow MISSED that (easily found) "Top of Forum Page Placement!"     How could the, "self-proclaimed, Forum Upgrade" have MISSED (again) - so obvious and UNIVERSAL (and needed!) "Tech DATA - User AID?"

    Thank you, Chester for another "Deep Dive" which is likely to prove, "Time, Energy, and Morale Saving" - for many here...