MSP430F6779A: RTC has stopped

Hello,Vikas Chola

Thank you for your reply.

Since the RTCHOLD bit is cleared, I was expecting RTCSEC to advance by 1 second with the RTCLOCK function enabled.

The RTCSEC value did not seem to change.

If RTCLOCK bit = 0, I confirmed that RTCSEC advances by 1 second.
How about guessing that RTCLOCK is enabled / disabled?

Best regards,
DDdoor

Hello DDdoor,

RTCLOCK shouldn't stop advancing RTC. it might be some other issue.. Can you share your initialization code for both condition so that I may go through it.

Regards,

Vikas Chola

Hello DDdoor,

One additional point is : When you are powering the device first time, you first do all initialization of RTC_C and finally set RTCLOCK bit. It might possible that you are setting this bit before ,due to this Some setting might not be effective while you made it in registers.

Please find below flow of code for RTC:

• Power on
• Check RTCLOCK bit (this will let you know if it is first time power on or so as it will be clear in First time Power on case)
• If RTC lock is clear, DO RTC initialization
• Clear RTCHOLD
• SET RTCLOCK

• If RTCLOCK is set , you know it is not first time Power ON so RTC is already initialized and no need for anything. If you need to do something with RTC sue to your application, you might implement it by clearing RTCLOCK. Make sure RTCHOLD bit, change setting , clear RTCHOLD and SET RTCLOCK.
  

Please check that in your code.

If you are able to make your code working, Put this reply as solution to your problem.

Regards,

Vikas Chola

Hello DDdoor,

Please advise if your problem has solved or you are facing any issue still.

regards,

Vikas Chola

Hello,Vikas Chola

Thank you for the additional contact.
I tell it to the customer.
I will contact you again if I get the result the customer tried.

Best regards,
DDdoor

Hello,Vikas Chola

I will send a private email with the source file that the customer has confirmed.

Best regards,
DDdoor

Hello Vikas Chola

This is a continuation of the other day.
When RTCLOCK = 1, RTCSEC was confirmed to count properly, and a soft reset was performed in the debugger.
When the customer checked the register, HOLD was 1. Since the customer did not know when RTCHOLD would be cleared,
the customer proceeded with the program, but HOLD remained at 1.

In the comment of the sample, it was written that the actual value was not reflected when read with the debugger as follows.
If this is read from the program, not from the debugger, is it okay if HOLD = 0?

The customer wants to check RTCHOLD. If Hold = 1, the customer thinks the HOLD needs to be cleared.
Can customers use this RTCHOLD to check if the RTC is working?
(Of course, the customer has read that the user does not need to clear HOLD during LOCK.)

//sample design comment
// MSP430F67791 Demo - AUXVCC3 Demo, Charger Enabled
// MSP430F6779_AUX_05.c

Please note that when the RTCLOCK bit is asserted,
some of the register bit values(such as RTCHOLD), which can be seen in the debugger,
may not reflect the actual operation of the RTC.

Best regards,
DDdoor

Part Number: MSP430F6779A

Hello Vikas Chola

This is a continuation of the other day.
When RTCLOCK = 1, RTCSEC was confirmed to count properly, and a soft reset was performed in the debugger.
When the customer checked the register, HOLD was 1. Since the customer did not know when RTCHOLD would be cleared,
the customer proceeded with the program, but HOLD remained at 1.

In the comment of the sample, it was written that the actual value was not reflected when read with the debugger as follows.
If this is read from the program, not from the debugger, Is RTCHOLD definitely 0?

The customer wants to check RTCHOLD. If Hold = 1, the customer thinks the HOLD needs to be cleared.
Can customers use this RTCHOLD to check if the RTC is working?
(Of course, the customer has read that the user does not need to clear HOLD during LOCK.)

//sample design comment
// MSP430F67791 Demo - AUXVCC3 Demo, Charger Enabled
// MSP430F6779_AUX_05.c

Please note that when the RTCLOCK bit is asserted,
some of the register bit values(such as RTCHOLD), which can be seen in the debugger,
may not reflect the actual operation of the RTC.

Best regards,
DDdoor

Hi DDdoor,

I will go ahead and ping Vikas to continue providing support regarding this issue. Thank you for your patience.

Best regards,

Matt

Hello DDdoor,

I couldn't understand what customer wish to put a logic from your description. When MCU will get RESET (Software/hardware), RTC registers which are not backed up by AUXVCC3 will reset to their default value (RTCHOLD bit default value is 1) , However These registers setting will make any impact on RTC functioning only  in case RTCLOCK is cleared:

Please see note in below figure:

If customer is looking to write some logic based on RTCHOLD bit, they can make it clear as it is RW (read/write) bit.

Regards,

Vikas Chola

Hello Vikas Chola,
Thank you for your reply.

The figure was not visible.

Now the user is not in an environment where they can experiment with AUXVCC3, but the power is always on.
RTCLOCK = 1 is set and RTCHOLD is set to be cleared. Therefore, the customer expects RTCHOLD to become 0 when a soft reset is given from the debugger. However, looking at the registers in the CCS GUI, RTCHOLD = 1 remains.

Can the user trust the value of RTCHOLD = 1 at this time?
Or since it is debugger information, shouldn't customers trust the value?

The following is a description of the impact of the debugger on the document.
One thing to note is that if RTCLOCK is set, the configuration of the bits locked by
RTCLOCK may be held but not the bits themselves (i.e.the value of affected bits in the debugger may not
reflect the actual configuration when the RTCLOCK feature is enabled).

Where and where are the values that should not be trusted when read by the debugger?

Best regards,
DDdoor

Hello DDdoor,

I have pasted RTCCTL1 description and Note which is given in the user guide section 24.4.3. You can go through it in MSP430F677x User guide.

One can change RTCCTL1 bits by writing or through RESET etc, it actually gets changed and debugger shows those valuea but if RTCLOCK is set then these bits change doesn't impact RTC functionality. For making these bits change effective for RTC functionality one need to make RTCLOCK=0

RTCHOLD will set to 1 after every RESET but it will not impact RTC functionality due to RTCLOCK bit is already set. Hope I could explain the functionality of RTCHOLD and RTCLOCK now.

Regards,

Vikas Chola

Hello Vikas Chola,

Thank you for your reply.

As you say, I understand that setting RTCCTL1 during RTCLOCK will not affect the RTC function because it will be ignored even if the register value is changed.
Then, when reading the register of RTCCTL1, is the value correct?
When a customer confirms using the debugger's soft reset function, even if the program is advanced a little, it appears that HOLD has not been cleared.
Originally, RTCHOLD is automatically cleared, but the RTCHOLD is not cleared on the debugger, so customers are worried. They really wonder if users don't have to clear RTCHOLD.

When will RTCHOLD be cleared?
Is there a specification such as how many clocks are cleared after?

Best regards,
DDdoor