Ooop's slight problem writing my previous thread.
In the 2nd test, the time is neither incremented, nor decremented by 60 minutes. So shifting from 00:59 to 01:00 does in fact nothing which is still uncorrect.
Apologize for this mistake.
Hmm, the clock should jump from 1:59 to 1:00. So your obviously in the wrong timezone for your test :)
Thanks for the reply, you're correct I'm wrong compared to European specs.
However, there is no direct relation as the shift is checked by the RTC firmware which applies intenal comparisons between the current time and the DST settings.
So even if my DST triggering hours are false, there is no reason not to correctly run with these values.
I'm now refering to this paragraph in the RTC component datasheet ():
'RTC_STATUS_DST – Status of Daylight Saving Time. This bit goes high when the current
time and date match DST time and date and the time is incremented. This bit goes low after
the DST interval and the time is decremented.'
Resetting the bord and setting the time one minute before DSTStop showed that the RTC_STATUS_DST was 0 before the shift and went to 1 after.
So this behavior follow the 1st part of the above stated rule. However setting the RTC time between March and October should have raised it in the RTC initialization. This wasn't the case.
Currently in this kind of situation it seems my RTC is running upside-down with respect to this status bit.
I should state that I first start the RTC component without filling its registers, I then set the DST registers and a while after thru the use of a PC dedicated software and the USB link, I setup the date & time framed by the RTC_Disable/EnableInt. May be I should start the RTC after all this setup to have the RTC-STATUS_DST bit correctly initialized?
What I meant is: on the last sunday of october, the time flows normally from 00:59 to 01:00 (this is what you tested and its correct). But then it jumps from 01:59 back to 01:00 - and you don't seem to have tested that.
According to the datasheet, a relative start/stop date for DST is converted to a fixed date at the end of the first hour after _Start() has beend called (and then one year after that). So your test routine should accomodate for that. (Maybe you can, for testing purposes, set a fixed DST start/stop date instead of a relative one. Dont forget to enable DST functionality when setting the mode register)
Sorry when I confuse you, but the time switchback is at 03:00h to 02:00h for the EU.
Nonetheless your observed behaving make me think, if the RTC is accepting an UTC which is then correctet according to your set timezone.
Since the original test was that DST turns on at 01:00, I was assuming that it works according to UTC.
Hli & All,
In fact once more I was interpreting the datasheet without strictly applying what is written.
After having dug deeper into it, I made the following evolution for each update sent by the PC:
RTC_currentTimeDate.DayOfMonth = xxx;
RTC_currentTimeDate.Month = xxx;
RTC_currentTimeDate.Year = xxx;
RTC_currentTimeDate.Hour = xxx;
RTC_currentTimeDate.Min = xxx;
RTC_currentTimeDate.Sec = 0;
RTC_WriteDSTMode(RTC_DST_ENABLE | RTC_DST_RELDATE);
RTC_WriteDSTStartHour(2); // 01:59 => 03:00
RTC_WriteDSTStopHour(3); // 02:59 => 02:00
RTC_Init(); // Mandatory for each update to be applied correctly
I may close this post, everything works right now (but wasn't really a piece of cake, a real good example would have help and save time ...)