RTC LSE source not being selected

Official Hardware Portenta Family Portenta H7
1

I am trying to get the RTC of the stm32h7 to run for a project. Since I didn't get any library working with this RTC like I wanted it to I decided to make it work through processor registers. Currently I have this sketch:


#include "Arduino.h"
#include "stm32h747xx.h"
#include "time.h"
#include "rtc_api.h"

uint8_t year_tens, year_units, month_tens, month_units, day_tens, day_units, hour_tens, hour_units, minute_tens, minute_units, second_tens, second_units;
time_t t;
struct tm timeS;

void setup() {
  Serial.begin(9600);
  while (!Serial);
  // Enable backup domain access
  PWR->CR1 |= PWR_CR1_DBP;

  // Select LSE as RTC clock source 
  RCC->BDCR &= ~RCC_BDCR_RTCSEL;
  RCC->BDCR |= RCC_BDCR_RTCSEL_0;

  // Enable RTC
  RCC->BDCR |= RCC_BDCR_RTCEN;
  rtc_init();
  setRTClock(2025, 11, 4, 16, 11, 30);
}

void loop() {
  updateTimeDate();

  Serial.println(t);
  
  printRTC();
  delay(10000);
}

String getWeekday() {
  const String days[8] = {"Error", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"};
  return days[timeS.tm_wday];
}

void setRTClock(int year, uint8_t month, uint8_t day, uint8_t hour, uint8_t minute, uint8_t second) {
  uint32_t dateRegister = 0;
  uint32_t timeRegister = 0;

  RTC->WPR = 0xCA;
  RTC->WPR = 0x53; //Write protection
  
  RTC->ISR |= RTC_ISR_INIT; //initialization
  Serial.println(RTC->ISR, BIN);
  Serial.println(RCC->BDCR, BIN);
  while(((RTC->ISR >> RTC_ISR_INITF_Pos) & 0x1) == 0); //wait for initialization to begin

  dateRegister |= dec2bcd(day);
  dateRegister |= (dec2bcd(month) & 0x1F) << RTC_DR_MU_Pos;
  dateRegister |= (dec2bcd(year % 100) & 0xFF) << RTC_DR_YU_Pos;
  RTC->DR = dateRegister; //write DR 

  timeRegister |= dec2bcd(second) & 0x7F;
  timeRegister |= (dec2bcd(minute) & 0x7F) << RTC_TR_MNU_Pos;
  timeRegister |= (dec2bcd(hour) & 0x3F) << RTC_TR_HU_Pos;
  RTC->TR = timeRegister; //write TR 

  RTC->ISR &= ~RTC_ISR_INIT; //clear init bit to end initialization
  RTC->WPR = 0xFF;
}

uint8_t dec2bcd(uint8_t val) {
  return ((val / 10) << 4) | (val % 10);
}

void printRTC() {
  Serial.println("Date: " + String(timeS.tm_mday) + "." + String(timeS.tm_mon + 1) + "." + String(timeS.tm_year + 1900) + " Time: " + String(timeS.tm_hour) + ":" + String(timeS.tm_min) + ":" + String(timeS.tm_sec));
  Serial.println("Weekday: " + getWeekday());
}

void updateTimeDate() {
  year_tens = (RTC->DR >> RTC_DR_YT_Pos) & 0xF; 
  year_units = (RTC->DR >> RTC_DR_YU_Pos) & 0xF;
  
  month_tens = (RTC->DR >> RTC_DR_MT_Pos) & 0x1; 
  month_units = (RTC->DR >> RTC_DR_MU_Pos) & 0xF;
  
  day_tens = (RTC->DR >> RTC_DR_DT_Pos) & 0x3; 
  day_units = (RTC->DR >> RTC_DR_DU_Pos) & 0xF;
  
  hour_tens = (RTC->TR >> RTC_TR_HT_Pos) & 0x3; 
  hour_units = (RTC->TR >> RTC_TR_HU_Pos) & 0xF;
  
  minute_tens = (RTC->TR >> RTC_TR_MNT_Pos) & 0x7; 
  minute_units = (RTC->TR >> RTC_TR_MNU_Pos) & 0xF;
  
  second_tens = (RTC->TR >> RTC_TR_ST_Pos) & 0x7; 
  second_units = (RTC->TR >> RTC_TR_SU_Pos) & 0xF;

  //Epochtime
  timeS.tm_year = ((2000 + year_tens*10 + year_units) - 1900);
  timeS.tm_mon = ((month_tens*10 + month_units) - 1);
  timeS.tm_mday = (day_tens*10 + day_units);
  timeS.tm_hour = (hour_tens*10 + hour_units);
  timeS.tm_min = (minute_tens*10 + minute_units);
  timeS.tm_sec = (second_tens*10 + second_units);
  t = mktime(&timeS);
}

Currently I can set the date and time and read it out properly. My problem starts when I noticed that the rtc was relatively inaccurate and it would loose about 1.5 minutes when running it for an hour or two. Then I noticed it was set up so the selected source for the RTC is LSI. To my understanding the 32.768kHz oscillator on the Portenta H7 (https://content.arduino.cc/assets/Schematic%20PDF_SL-ABX00042.pdf#[{"num"%3A42%2C"gen"%3A0}%2C{"name"%3A"FitR"}%2C0%2C547%2C828%2C0]) should be considered a LSE for the processor. As can be seen in the sketch I tried to manually set the RTCSEL bits to LSE, but when I print out the RCC BDCR register I get: 1000001000000101. Which means, that first off the LSE wasn't selected and instead the LSI was selected again and secondly the LSERDY bit never gets set. Plus the LSE Bypass bit is set for some reason, but I guess that must have something to do with the LSI being selected. Can anyone help me get this woking?
Thanks in advance!

2

Hi @nonameneeded1 , this should sort you out. It should work the same for Portenta H7 as it does for the GIGA.

https://forum.arduino.cc/t/a-guide-to-improving-your-giga-r1-internal-rtc-accuracy/

p.s. take a look here ArduinoCore-mbed/cores/arduino/mbed/platform/include/platform/mbed_mktime.h at main · arduino/ArduinoCore-mbed · GitHub these work well and no need to resort to registers

1 Like
3

Hey, first off thanks for the reply, but sadly this didn't really help me. I did try to set the bits for the LSE Drive capability to high, but again when I printing out the BDCR register I noticed that it didn't even change the corresponding bits (output was still 1000001000000101). My guess is that this has something to do with the LSE not being selected in the first place, but honestly no idea what is happening there. The calibration thing in the post you linked to is nice and all, but my main problem is not getting the LSE selected in the first place. I don't even know how much the drift of the LSE would be because right now the RTC is only using LSI as its source.
Any other ideas?

4

If the FixRTC class drive level override didn't work then I guess the portenta H7 is set up differently. I did notice the targets.json mbed file has the portenta lse_bypass set to use an oscillator whereas the GIGA is set to use a crystal. Not sure it's relevant, but it is different.

Hopefully the Arduino team might be able to assist

5

wait actually.... I did something stupid yesterday because I didn't sleep well enough. The FixRTC class did actually set the LSE Drive bits correctly to HIGH capability. But it still remains, that the Bypass bit is set and the LSI remains selected instead of the LSE.

Tried adding LL_RCC_LSE_DisableBypass(); LL_RCC_SetRTCClockSource(LL_RCC_RTC_CLKSOURCE_LSE); to the FixRTC class to maybe set it through these methods. Intrestingly enough it did disable the bypass and made it possible for LSERDY flag to be set by hardware. Sadly though it didn't select the LSE as the source.

6

How old's the board? Reference here to rev 1 having hardware bug RTC Clock Accuracy - #10 by egh

Also, noticed portenta has a macro LSE_STARTUP_TIMEOUT=200 set that no other H7 board has.

7

It's really new. Bought it like 2 months ago and say Rev2 on the packet. Anyway, it gets really interesting for me now. I did some more testing and concluded it was the rtc_init() from rtc_api.h function all along. So looking around the stm32h7xx_ll headers I managed to put this together:

class FixRTC {
public:
    FixRTC() {
        LL_PWR_EnableBkUpAccess();
        LL_RCC_LSE_Disable();
        LL_RCC_LSE_SetDriveCapability(LL_RCC_LSEDRIVE_HIGH);
        LL_RCC_LSE_DisableBypass();
        LL_RCC_SetRTCClockSource(LL_RCC_RTC_CLKSOURCE_LSE);
        LL_RCC_LSE_Enable();
        LL_RCC_EnableRTC();
    }
};

FixRTC fixrtc __attribute__ ((init_priority (101)));

This actually manages to enable the RTC and set it to LSE when I remove the rtc_init() function from the setup code.

8

Ok, thanks for the help getting the LSE to work, but now I have a weird problem: The clock is now even more wildly inaccurate. What I mean is that in about 10 seconds it counts only 5 seconds. Why is this? Is it a setup issue?

9

Good work on getting the LSE in play. Never seen anything like that with the ticks.

I suggest removing the rtc battery (if you have one) and power from the board. Don't set date/time in your sketch and then loop round with:

_rtc_localtime(time(nullptr), &timeStamp, RTC_FULL_LEAP_YEAR_SUPPORT);

to read and eliminate your register manipulation as a cause.

11

It just keeps on getting more bizarre.

So I commented out my functions for setting and reading the registers and added the rtc_localtime method and it seemed to work fine until I noticed the time drifting again. Then I looked closer and noticed for some reason the rtc_localtime method resets my clocksource back to LSI. This makes absolutely no sense to me. Removing the method and only uncommenting the function I had for reading the time and date registers resulted in the LSE being selected properly, but the time falls behind really far again.

Even more weird I changed the delay from 10 to 1 second to more closely monitor the RTC and when I said it lost about 5 seconds every 10 seconds, I was seemingly lying. In reality it looses 1 second every 4 seconds. Constantly. I look at the serial monitor and every 4th count it repeats the same number again before continuing.

Do you have any clue why this would be?

12

Found some code in the portenta variant init routine. It looks like hacks for hw issues!

I think RTC/LSE on portenta H7 has issues

13

Well that's weird. I already noticed that RTC/LSE has problems, but why is there everything there for people like me who want to use it just to discover it's really quite difficult and doesn't even work properly once you get it "working". Also not even the first revision of this board.

So... is there any hope in me using the RTC on the Portenta H7? Because I am going slowly insane from this.

(Again thank you for the help, by the way)

14

On that particular board, it feels unlikely. It could be a bad board so my next step would be raising a ticket with Arduino here https://www.arduino.cc/en/contact-us/ linking to this thread. If they can't fix it then I'd go for a replacement. If that also fails then I'd look elsewhere

15

I was gonna use the RTC for another project and I already have another Portenta H7 board on hand (which was delivered about a week ago actually. Guess I got a bit too excited and didn't wait long enough for testing). I can tell you, uploading the same sketch both with and without rtc_localtime changed nothing about the outcome.

On one hand it would keep the same time for way longer than a second every now and again and on the other hand it would default back to the LSI.

Really just such a disappointment for me personally.

Thanks a lot for your help, I'll have to see if maybe someone else comments on this thread and otherwise leave the RTC idea completely behind me.

16

I'd still raise it via the contact form to see if they have any suggestions. I'm very happy with the GIGA RTC, it looses a second every three weeks or so.

Happy to help and glad some progress was made that might inform others