MSP430F5438: Alternative to majority vote when reading RTC counters

Hi Wenhao,

First, I need to warn you that the MSP430F5438 is not recommended for new designs. It has been replaced by the MSP430F5438A which has the same functionality and pinout.

Now on to your question. As Jens-Michael Gross stated "If you read the registers while the counter is in the process of updating, any value can appear in the register (racing condition on the digit-to-digit rollover)." This means there is a chance that when you first populate v1 and v2 by reading RTCNT, you could "incorrectly" read a value that passes your criteria (1 < v2 - v1) but that value is incorrect.

Additionally, if using the RTC in calendar mode, section 22.2.2.3 of MSP430x5xx and MSP430x6xx Family User's Guide describes other methods of properly reading registers. However, from what I've gathered it looks like you're using the RTC in counter mode?

Best regards,
Caleb Overbay

Hi Caleb,

Yes, we're using the RTC in counter mode.

But, assuming that the CPU's clock is much faster than the RTC's, and meanwhile it is slow enough when compared to the speed of the transition in the counter hardware, at most one of v1, v2 could hit the transition:

• If v1 hits, then v2 is correct and returning v2 is always appropriate;
• if v2 hits, then v1 is correct, and if the criteria is meet, v2 is either the same as v1 (as though v2 hits right before the transition) or is one greater than v1 (as though v2 hits right after the transition), and both are appropriate.

Did I miss something? Thank you.

Hi Caleb,

We run RTC at 32768Hz, and CPU at several MHz.

Hi Caleb,

Caleb Overbay said:

with the CPU running much faster than the RTC source, there is a chance both v2 and v1 are incorrect readings

In my opinion, the CPU speed, which determines how frequent we can read the RTC counter, should be compared to the speed of the transition in the RTC counter hardware, which ought to be driven by rising edges of the RTC clock. Therefore, the speed of the transition should be very high and nearly fixed (even not affected by the slope of the clock edges, not to mention the frequency of the clock). And, anyway, the majority vote algorithm also suffers from "both v2 and v1 are incorrect", as I mentioned in my first post.

Caleb Overbay said:

The method you've described above would work best when the CPU and RTC sources are much closer in frequency.

On the contrary, the single fatal flaw of my proposal, I suppose, is that it cannot deal with the very case you mentioned above. When the CPU does not run fast enough, v2 can be two or more greater than v1 even in normal cases, which causes the while to loop endlessly.

Hi Caleb,

Caleb Overbay said:

essentially the method Jens-Michael Gross has described.

I totally agree with you.

Caleb Overbay said:

It's highly unlikely that you'll get two incorrect readings that are identical from the initial reads.

First, could you please explain this statement a little more? It's not quite clear for me, especially the word initial (sorry, English is not my mother tongue). Second, with CPU running at tens of MHz, I hope it's "impossible", not just "highly unlikely". :-)

Caleb Overbay said:

I apologize if I caused any confusion. It's always good to review these things with peers!

I really appreciate your help. That's why I am here in the first place!

I do most of my work in assembler and would recommend the following way (here as a macro - more speedy). Pls keep in mind that this macro is only suitable in counter mode: The "xT" comments denote the numbers of MCU clock cycles.

// Minimum total duration: 15 MCU cycles
// Maximum total duration: 18 MCU cycles
M_RTC_READCNT MACRO
        local locExit
        mov &RTCNT12,R14   // 3T 1st read of counter low word
        mov &RTCNT34,R13   // 3T Read counter high word
        mov &RTCNT12,R12   // 3T 2nd read of counter low word.
        cmp R12,R14            // 1T Both readings of low word identical?
        jeq locExit            // 2T If yes: Everything's fine - R12 and R13 already hold correct values
        mov &RTCNT34,R13   // 3T If a change occured then the first reading of RTCNT34 may not have been correct.
locExit:
        ENDM

Nope. Your code can only deal with the synchronous case. When things are asynchronous, even reading a single byte (say RTCNT1) can give you unpredictable results.