MSP430F6779: Questions about the RTCRDY time

Thank you for your question,

An assigned MSP team member will assist you shortly with this issue.

Hi

I have additional questions.

RTCHOLD stops updating RTC's counter, but when RTCHOLD is changed from 0 to 1 or 1 to 0, does HTCRDY change?

When RTCRDY is 0, does writing a RTCHOLD cause no problem?
(Write and read, subsequent actions, etc.)

When RTCRDY is 0, does RTCRDY change when RTCHOLD is set to 1?

When I want to do a secure read with RTCRDY, does it need a delay to read after RTCRDY changes from 0 to 1?

Regards,
Da

Hello Da,

da said:

Ask questions about the HTCRDY time.

I'm not familiar with HTCRDY. I'm assuming you mean RTCRDY.

da said:

RTCRDY is stated to go low during the keep-out window.
In the manual, the time of keep-out window is 128/32768.
Since the clock is 32768 Hz, it takes 3.9 ms. Is this correct with this calculation?

I'm assuming you're using calendar mode. Your calculation seems correct.

da said:

Actually, the first measurement was 3.9 ms, and then 7.8 ms could be measured every second.
There are two types of time, is this correct?

The User's Guide does mention it's an approximate keep-out window of 128/32768. This could vary based on this description. Are the results getting updated correctly each second? Please be mindful to follow the recommended method for reading out the real-time clock registers.

Regards,

James

> I'm not familiar with HTCRDY. I'm assuming you mean RTCRDY.

Yes, it is a mistake of RTCRDY.

> The User's Guide does mention it's an approximate keep-out window of 128/32768.
This could vary based on this description. Are the results getting updated correctly
each second? Please be mindful to follow the recommended method for reading out
the real-time clock registers.

I did not measure for a long time, but RTC worked without problems.

Execute a program that sets GPIO high while RTCRDY is low.

The first

Second and subsequent times

Please answer the following questions as well.

1. RTCHOLD stops updating RTC's counter, but when RTCHOLD is changed from 0 to 1 or 1 to 0, does HTCRDY change?

2. When RTCRDY is 0, does writing a RTCHOLD cause no problem?
   (Write and read, subsequent actions, etc.)

3. When RTCRDY is 0, does RTCRDY change when RTCHOLD is set to 1?

When I want to do a secure read with RTCRDY, does it need a delay to read after RTCRDY changes from 0 to 1?

Regards,
Da

da said:

I did not measure for a long time, but RTC worked without problems.

That's good to hear.

da said:

Please answer the following questions as well.

1. RTCHOLD stops updating RTC's counter, but when RTCHOLD is changed from 0 to 1 or 1 to 0, does HTCRDY change?

2. When RTCRDY is 0, does writing a RTCHOLD cause no problem?
   (Write and read, subsequent actions, etc.)

3. When RTCRDY is 0, does RTCRDY change when RTCHOLD is set to 1?

Setting RTCHOLD halts the counter and clears RTCRDYIFG even if it's set by RTCRDY. Resetting RTCHOLD (1 to 0) then allows RTCRDYIFG to get set by RTCRDY. This is illustrated in Figure 24-1 in the User's Guide. Whether or not RTCRDY is set or not shouldn't matter since you want to read the RTC registers when RTCRDYIFG is set.

da said:

When I want to do a secure read with RTCRDY, does it need a delay to read after RTCRDY changes from 0 to 1?

According to Section 24.2.5 in the User's Guide, "an interrupt is generated based on the rising edge of the RTCRDY bit, causing the RTCRDYIFG to be set. At this point, the application has nearly a complete second to safely read any or all of the real-time clock registers".

MSP430F6779: I have a question about RTC.

Regards,

James

Hi,

Could you give us an opinion on the following matters individually?

1. RTCHOLD stops updating RTC's counter, but when RTCHOLD is changed from 0 to 1 or 1 to 0, does HTCRDY change?

2. When RTCRDY is 0, does writing a RTCHOLD cause no problem?
   (Write and read, subsequent actions, etc.)

3. When RTCRDY is 0, does RTCRDY change when RTCHOLD is set to 1?

When I read RTC data, I understand that it is recommended to do by
an interrupt or to check and read RTCRDYIFG?
Therefore, it takes one second to set the RTC and read it reliably.

I asked a question about loading,
An error has occurred when updating the RTC time.
Writing 5:00:00 to 4:59:59 results in 5:59:59.
It is likely that there is a problem with reading or writing.

Is there a recommended way to write to a working RTC?

Also, we are updating RTCs quite often now.
How often do we update RTCs?

Regards,
Da

Hello,

da said:

Could you give us an opinion on the following matters individually?

1. RTCHOLD stops updating RTC's counter, but when RTCHOLD is changed from 0 to 1 or 1 to 0, does HTCRDY change?

2. When RTCRDY is 0, does writing a RTCHOLD cause no problem?
   (Write and read, subsequent actions, etc.)

3. When RTCRDY is 0, does RTCRDY change when RTCHOLD is set to 1?

Did you read through my comments in my previous post? I've already addressed these questions there.

da said:

I asked a question about loading,
An error has occurred when updating the RTC time.
Writing 5:00:00 to 4:59:59 results in 5:59:59.
It is likely that there is a problem with reading or writing.

Is there a recommended way to write to a working RTC?

You can read about how to read or write to the RTC registers in Sections 24.2.2 and 24.2.5 in the User's Guide. For reliable update to all Calendar Mode registers set RTCHOLD = 1 before writing into any of the calendar or prescalar registers (RTCPS0, RTCPS1, RTCSEC, RTCMIN, RTCHOUR, RTCDAY, RTCDOW, RTCMON, and RTCYEAR).

da said:

Also, we are updating RTCs quite often now.
How often do we update RTCs?

This would depend on how often you're required to update the RTC for your application. It could also depend on temperature compensation requirements as discussed in Section 24.2.8. I would recommend writing to the RTCs as little as possible to prevent the time from varying.

Regards,

James

Hi,

> Did you read through my comments in my previous post? I've already addressed these questions there.

I reread it, but I did not know if it was a corresponding answer.

Is the previous post the next combination?
My question is not about RTCRDYIFG, but about the operation of RTCRDY.
Is RTCRDY that can not be used as a reference for RTC operation?

Also, I checked the operation of RTCHOLD and RTCRDYIFG.
In the answer, when RTCHOLD is set to 0, RTCRDYIFG also becomes 0.
However, when RTCRDYIFG is 1, RTCRDYIFG does not become 0 even if RTCHOLD is 1.
(Refer to the figure below)

> 1. RTCHOLD stops updating RTC's counter, but when RTCHOLD is changed from 0 to 1 or 1 to 0, does HTCRDY change?

=> Setting RTCHOLD halts the counter and clears RTCRDYIFG even if it's set by RTCRDY.

> 2. When RTCRDY is 0, does writing a RTCHOLD cause no problem?
> (Write and read, subsequent actions, etc.)

=> Resetting RTCHOLD (1 to 0) then allows RTCRDYIFG to get set by RTCRDY.
This is illustrated in Figure 24-1 in the User's Guide.

> 3. When RTCRDY is 0, does RTCRDY change when RTCHOLD is set to 1?

=> Whether or not RTCRDY is set or not shouldn't matter since you want to read the RTC registers when RTCRDYIFG is set.

> I would recommend writing to the RTCs as little as possible to prevent the time from varying.

It is about every minute now, is there any problem?

RTCHOLD and RTCRDYIFG when RTCHOLD is set, executed and stopped

Regards,
Da

I have additional questions.

Currently, when updating RTC, RTCSEC and RTCMIN are not changed.

When updating, check RTCRDY and set RTCHOLD before updating.
Although the probability is low, the values of RTCSEC and RTCMIN will be the previous values of the updated value.

Add Question

Currently, we can only confirm that rewriting of RTCSEC and RTCMIN has failed.
Is it possible that other RTC registers RTCHOUR and RTCMON will fail to rewrite?

Add Question

Currently, rewriting in the order of year, month, second, day of the week, rewriting of RTCSEC, RTCMIN has failed.
Is there a possibility that the rewrite of the month or day may fail?
Order of writing
1. Year-> ok
2. Month-> NG
3. Day-> NG
4. Hour-> ok
5. Minutes-> ok
6. Second-> ok

Regards,
Da

According to the NOTE in Section 24.2.2 in the User's Guide, "for reliable update to all Calendar Mode registers Set RTCHOLD = 1 before writing into any of the calendar or prescalar registers (RTCPS0, RTCPS1, RTCSEC, RTCMIN, RTCHOUR, RTCDAY, RTCDOW, RTCMON, and RTCYEAR)".

Writing of invalid date or time information or data values outside the legal ranges specified in the RTCSEC, RTCMIN, RTCHOUR, RTCDAY, RTCDOW, RTCYEARH, RTCYEARL, RTCAMIN, RTCAHOUR, RTCADAY, and RTCADOW registers can result in unpredictable behavior.

I suspect that you're reading RTCSEC and RTCMIN registers after writing to them, so please make sure you're following the guidelines explained in the User's Guide for reading the RTCSEC and RTCMIN registers.

Regards,

James