2 bit RTC->DR problem for STM32F767 (corrected title)

[RKosst]

I am using STM32F767, unfortunately I have a problem with the DR register area in the RTC. Exactly the problem is with the 10th and 17th bits of this register. Setting "1" means that I am not able to change these bits to "0". Only resetting the BDCR helps. Interesting fact: In the case of automatic date change (i.e. from July 31 to August 1) bit 10 in the DT register is automatically reset. Where could the problem be?

[Peter BENSCH]

Welcome @RKosst​, to the community!

The RM0385 writes in this regard in section 29.6.2: The RTC_DR is the calendar date shadow register. This register must be written in initialization mode only.

Does it answer your question?

Regards

/Peter

[waclawek.jan]

If you are using 'F767, why do you have problem with 'F746?

> Setting "1"

How?

> am not able to change these bits to "0"

How are you trying to achieve that?

JW

[RKosst]

Sorry for the mistake in the title.

Peter BENSCH (ST employee) - thanks for the answer - yes I know you only need to write it down during initialization, but unfortunately I have to make corrections or changes to the date and time from time to time. How can I do it to be correct?

I am using the stm32f7xx_rtc.c library and the RTC_SetDate function. The effect is that I can set the day, day of the week, month and year. But if I just want to change, update the date, if "1" is entered in bits 10th and 17th of the DR register, it cannot be reset these bits

.

The processor will run in VBAT mode most of the time, but there will be times when it is updated or the time and date changes. How to do it so that the date is saved correctly? The time register is working properly.

[waclawek.jan]

> I am using the stm32f7xx_rtc.c library

What's that, SPL?

Show us exactly what did you do, so that somebody can try to reproduce that; and read out and post content of the RTC registers after each step.

JW

[waclawek.jan]

AFAIK there's no SPL for 'F7. Searching for "stm32f7xx_rtc.c" I stumbled upon your thread on elektroda.pl...

You've taken the 'F4 SPL function and renamed it, haven't you.

Often, problems like these are caused by improperly set/zeroed fields in the structs used for the function calls. So, stepping through RTC_SetDate(), observe content of tmpreg and any other variable in that function.

JW

[RKosst]

I have not changed the name. I am not using SPL. I write libraries myself as needed. As it didn't work for me, I started searching the internet. I found out of it "some" library and it turns out that it behaves the same. I don't understand why these 2 bits in the mentioned register cannot be changed.

e.g. https://github.com/juribeparada/STM32F7XX_Lib/tree/master/STM32F7xx_StdPeriph_Driver

[waclawek.jan]

> I don't understand why these 2 bits in the mentioned register cannot be changed.

Often, problems like these are caused by improperly set/zeroed fields in the structs used for the function calls. So, stepping through RTC_SetDate() (in debugger), observe content of tmpreg and any other variable in that function.

JW

[RKosst]

Actual value DR = 0x22a624, For August 1, 2022, the value of tmpreg = 0x222801.

as a result of writing data to the DR register, I got a value from that register 0x222c01. Function end status = success.

When I return to the settings, e.g. on July 31, 2022, the DR register will be OK after the modifications. If, as a result of RTC operation, the date automatically changes to August, the data in the DR register will be correct. The same is true for the area of ​​the year, where it applies to 17bit . I would like to mention that this is not a hardware problem as I will check it on several PCBs and on different projects.

[waclawek.jan]

In debugger, place a breakpoint just before the point where RTC->DR is to be written. Read out and post all RTC registers. Then single-step in disasm, observing, which register is being written into RTC->DR and what it its content. After write, again read out and post all RTC registers.

JW

[EDIT] What I'm trying to say is, that hardware bugs are extremely unprobable, and in the vast majority of cases it's user error, in one form or other. I don't say hardware bugs are nonexistent, but that you should go all the way down to the very basics to exclude software error first. One way to do that is single-stepping in disasm, and observing both processor's and RTC's registers, as I've described above. You can even experiment with writing to RTC registers (and PWR/RCC as needed) in debugger, while the mcu is stopped.

Other method is to write an absolutely minimal but complete compilable program exhibiting the problem. At the end of the day, if it's a problem, it has to be reproducible at other places, too.

One other thing which came into my mind is, once you've definitively excluded software error, do you have a "known good" hardware such as a Nucleo or Disco board, to try this on them? Can't this be some power supply/VBAT issue?