EK-TM4C1294XL: Interrupt missing when using a smaller RTC Trim than the nominal value (0x7FFF)

Hi Cameron,

  Are you in RTC counter mode or calendar mode? Based on your description you seem to be in calendar mode as you are skipping 60 seconds rather than 64 seconds. Maybe another question to ask is do you want your application in counter mode or calendar mode? If you want to be RTC counter mode, I will expect the trim to apply every 64 seconds rather than 60 seconds for calendar mode. 

Please also see below datasheet description about setting the trim value that is very near to the sub seconds match value. Is this what you are seeing? What is your sub-seconds match value? 

Care must be taken when using trim values that are near to the sub seconds match value in the
HIBRTCSS register. It is possible when using trim values above 0x7FFF to receive two match
interrupts for the same counter value. In addition, it is possible when using trim values below 0x7FFF
to miss a match interrupt.

In the case of a trim value below 0x7FFF, the RTCSSC value is advanced from 0x7FFF to the trim
value while the RTCC value is incremented from 0x0 to 0x1. If the match value is within that range,
the match interrupt is not triggered. For example, as shown in Figure 7-6 on page 542, if the match
interrupt was configured with RTCM0=0x1 and RTCSSM=0x2,an interrupt would never be triggered.

Cameron Hughes said:

workaround 1: Just use another timer. This is ok but my timestamp output will not be synchronous with what is it being triggered with, so I could technically get double readings of the same time or a missing reading. I could set RTC to a time variable in software and increment the time in software via a separate timer, output would be synchronous but won't be able to use interrupts to wake?

If you are in hibernate mode, then only hibernate module and RTC will be active.  i don't think other timers can be used as their logic is in sleep. 

Cameron Hughes said:

workaround 2: Somehow get RTC Match interrupt to not care about sub-seconds and interrupt when we get a 1s change. I think this might work, but I don't know if it is possible.

If you are in RTC counter mode then both the seconds and sub-seconds will be compared. 

Cameron Hughes said:

workaround 3: Can't we set it up to interrupt if we are >= match value, not just ==?

According to the datasheet, it is a ==, not >=. 

Cameron Hughes said:

workaround 4: another method of trimming?

If you can set the sub-seconds match value that is not in the range of trim counting (see figure 7-6 for example) then it may work. 

Hello, thanks for the response.

Sorry, I should've mentioned that I am using Calendar mode and so I am matching at a specific date/time down to the second (current time + 1s).

From the datasheet:

Care must be taken when using trim values that are near to the sub seconds match value in the
HIBRTCSS register. It is possible when using trim values above 0x7FFF to receive two match
interrupts for the same counter value. In addition, it is possible when using trim values below 0x7FFF
to miss a match interrupt.

I don't even set the sub seconds match value - it is set to 0 as default. Should I need to worry about the sub second counter? I'm struggling to see how and why it is affecting my Calendar match.

HI Cameron,

  I modified the TivaWare example C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\hibernate_calendar to wake in one second and I also tried a couple of different trim values that are less than 0x7FFF. I was always able to wake up after the RTC reaches its +1s match value. Can you also try the example and do you see any different behavior? Also can you repeat the same problem on a different board?

Hello, I've tried the example and I'm getting the same issue.

If you send the 'hib' command at 00:00 just before the skip to 00:02 it will never wake.

My edits to the example:

added to line 772:

//set an unusual trim
MAP_HibernateRTCTrimSet(0x03);

edit to line 421:

sTime->tm_sec += 1;

Hi Cameron,

  I see the hibernate count equal to 74 on your screenshot. Did it work for 74 times and then fail? Or that was the left over from the previous run before you inserted the trim value?

  Do you have another board to try?

it always works if the RTC isn't ticking over from 00:00 to 00:02 (on every minute). The 74 times was me just checking.

I don't have another TM4C1294 to try out now, only TM4C123 which doesn't have calendar mode anyway...

Can you not reproduce?

Cheers,

Cameron

Ok, I tried your trim value (0x3). Not until 18 times did it freeze and not wake up. I don't really understand what went wrong. 

my guess - on your example posted above:

Calendar match interrupt is set to go off at 08:32:01 (1s ahead)

Because the RTC Trim is set so low, 08:32:01 is skipped and the calendar goes from 32:00 -> 32:02

Wake never triggers... I can't think of a simple solution to this.

I agree with your reasoning. I tried the example again and notice that it only fails when it needs to change from 32:00 to 32:01. This means the trim is applied at the 60s boundary. I was experimenting with the wake up at 2s increment and although not exhaustive, I didn't see it fail. 

Although not exhaustive, I try an experiment with wake up at 1s interval but set the sub-seconds match register to an arbitrary value that is away from the trim value to cause the wake up not to be missed. It seems to work. 

HibernateRTCTrimSet(0x7FF0);
//
MAP_HibernateRTCSSMatchSet(0, 12345);

I haven't had time to analyse the programs in this thread, but do remember previously reporting TM4C123GH6PM: Discrepancies in description of RTC Trim in datasheets. While the thread title mentions a TM4C123, the notes in thread mention a TM4C129 behaves in the same way.

Not sure if relevant to the issue in this thread.

Hi Chester,

  Thank you for digging up this old thread you wrote. Really appreciated. The OP as well as myself are seeing the missing of wake up interrupt which is a bit different from your finding. I will spend some time to understand your test program again. 

By setting the RTCSS Match value aren't you affectively adding a positive trim to every second (increasing the tick) therefore requiring an even smaller RTC trim value, meaning that you essentially face the same issue as soon as you get down to reducing it to <1s (as you skip that interrupt once again). Maybe it could work if you could set an offset where the RTCSS counter starts at an appropriate value too...?

So although this works, it would seem to completely remove all reason to use the trim in the first place?

Hi Cameron,

  My intent was merely to avoid skipping interrupt. You set the trim value to whatever that is appropriate to fine tune the 32kHz XOSCIN. Every 60 seconds, the trim will be applied regardless of what sub-seconds value is applied. It seems that in the calendar mode, the sub-seconds value of 0 is used. With this assumption, at every 60 seconds boundary, it matches the second (where you set 1s interval) and sub-seconds (0 by default), this is why it does not generate an interrupt. I was hoping to move the sub-seconds away from 0 so that the match event is not in the window of the trim value. I don't know how much your 32kHz crystal is off from the ideal. The best way to find out is to see how much the time drifts without the trim over a day vs with the trim applied and sub-seconds match value that is away from the window.