• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 2227 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430F5438: RTC_A working as timer, 0.007% rate that the calculate time is not we expected

Daniel Fang
Genius 11600 points
Part Number: MSP430F5438

Hi

Could you give some more explanation about  below "asynchronous"?

My customer make RTC_A working as timer, it has 0.007% rate that the calculate time is not we expected.

The low 8bit RT0PS give +1 overflow information to high 8 bit RT1PS,  high 8bit RT1PS should be increase +1. We catch the situation that it's not increase +1, and low 8bit  RT0PS is already cleared to 0x00. 

Is it caused by asynchronous clock between ACLK and MCLK? Thanks.

  • 0
    TI__Genius 15370 points

    Hi Daniel,

    Asynchronous in this scenario means that the RTC has a different clock source than the MCLK does. It's most likely not the cause of the issue your customer is experiencing. Have they verified that the clock sourcing the RTC is running at the frequency they expect?

    Can you provide more detail about their use of the RTC including their initialization code and any RTC interrupts being used? Also the clock source setup code would be helpful as well. It would be ideal if your customer could create the smallest set of code possible that recreates the issue so I can try testing it on my setup.

    Best regards,
    Caleb Overbay

  • 0
    TI__Genius 15370 points
    Hi Daniel,

    Does your customer still need help with this issue?

    Best regards,
    Caleb Overbay
  • 0
    Intellectual 820 points

    Clocking source is not really relevant. The point of the note is that rollover can occur at ANY time unless counting is halted. so rollover can and presumably WILL occasionally occur between high and low  register reads, REGARDLESS  OF READ ORDER, so one must  allow for / protect against said situation.

    as an example, let's assume a generic microcontroller having a 16-bit counter implemented as two separate byte-wide registers. initial conditions of the counter are high-byte = 3 and low = 0xff, and rollover occurs between register reads

    scenario 1 : high is read as 3, rollover occurs,  low is read as 00  final result hex 300         incorrect 

    scenario 2: low is read as 0xff, rollover occurs,  high is read as 4 final result 0x4ff             incorrect

  • 0 in reply to Jeff Hastings
    TI__Genius 15370 points
    Hi Jeff,

    The note in the original post is discussing how to properly read the count registers when the CPU clock is asynchronous to the RTC. This is has nothing to do with overflow within the count registers. Since the CPU clock is asynchronous to the RTC clock you don't know when the count register is being updated. So a read from it could occur during a "tick" of the count register resulting in a bad read. When this occurs you need to take multiple reads of the same register and perform a majority vote to determine which is correct.

    I acknowledge that the scenarios you've described could be an issue when stringing together two timers but it's not the heart of the issue here.

    Best regards,
    Caleb Overbay
  • 0 in reply to Caleb Overbay
    Intellectual 820 points
    Noted. I have always assumed a read of a single counter register could not be incoherent ... guess I should not.

**Attention** This is a public forum