• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 81 subscribers
  • Views 746 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTC Calendar Month change bug

Paul Young
Intellectual 310 points

Other Parts Discussed in Thread: CC430F5137, MSP430WARE

so I've RTC_A setup awesomely in calendar mode with backup battery and all & it's working great, up until I noticed some weird behaviour when it comes to month changes.

In my code I've integrated time.h to as its use is necessary throughout the rest of the code. This was achieved by having code that converted the MSP "Calendar" data type into the "struct tm" data type. I noticed the following trend yesterday

Date set (dd/mm) Date after midnight
31/01 01/02
28/02 01/03
31/03 01/04
30/04 01/05
31/05 02/06
30/06 01/07
31/07 02/08
31/08 01/09
30/09 01/10
31/10 02/11
30/11 01/12
31/12 02/01

Anyone noticed anything like this before?

  • 0
    Guru 92251 points

    Paul Young said:
    Anyone noticed anything like this before?

    I have checked the month changes in a CC430F5137 which has a RTC_A, and all month changes were correct in both BCD and hexadecimal counting modes. driverlib in MSP430ware was used to initialise the RTC and then read the RTC once per second via the RTC Ready interrupt.

    Which MSP430 are you seing the problem in, and can you post your code?

  • 0
    Guru 58965 points

    The mistake is in the day-of-month when a month with 30 days ended and a new month with 31 days started.

    You (or someone) probably made the date change part of the code unnecessarily complicated and obscured an otherwise obvious mistake.

  • 0 in reply to old_cow_yellow
    Expert 2505 points

    What OCY is probably suggesting is that RTC_A numbers months from 1 through 12, while struct tm numbers them from 0 through 11.  It's likely an error in the translation between the representations would explain the anomaly.  Always check the base number; for the DS3231 I was working with yesterday it was day-of-week that caused grief (0-6 POSIX, 1-7 DS3231).

**Attention** This is a public forum