cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H755 - RTC->SSR & RTC->SHIFTR

ravo
Senior

Dears, I have issues with setting RTC shift register.

I have setup RTC with AsynchPrediv = 127 & SynchPrediv = 255 and is working normally.

I tried to periodically setting RTC->SHIFTR with value 100 each 5 secs. Then wait for the shift operation to complete and immediately I read SS back using register RTC->SSR register. But RTC->SSR provide "random values" in PREDIV_S range (0 - 255). I expect that it should be lower than 100 but close (not higher)

Where could be problem ?

Thanks in advance

Radim

Example code:

 

 

int main(void)
{
 unsigned this_ssr, tick, tr, dr;
 reset_backup_domain();
 ...
 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_USART3_UART_Init();
 MX_RTC_Init();
 ...

 // Turn on shadow registers to speed up RTC operations
 HAL_RTCEx_EnableBypassShadow(&hrtc);
 ...
 
while(1)
{
 __HAL_RTC_WRITEPROTECTION_DISABLE(&hrtc);
 HAL_PWR_EnableBkUpAccess();
 RTC->SHIFTR = 100; // test value 
 // Wait for the shift operation to complete
 while ((hrtc.Instance->ISR & RTC_ISR_SHPF) != 0) {}
 HAL_PWR_DisableBkUpAccess();
 __HAL_RTC_WRITEPROTECTION_ENABLE(&hrtc);
 
 /* Read all 3 registers. */
 this_ssr = READ_REG(RTC->SSR);
 tr = READ_REG(RTC->TR);
 dr = READ_REG(RTC->DR);
 
 HAL_Delay(5000); // wait cca 5 sec
}

 

 

 

13 REPLIES 13

> I expect that it should be lower than 100 but close (not higher)

Why would you expect that?

waclawekjan_0-1733309167043.png

Note, that as consequence of shift, SSR can even get higher than the synchronous prescaler - description of SSR register warns for that.

JW

ravo
Senior

Dear  @waclawek.jan ,

thanks for response. Yes of course I have omitted this, I of-course read TRM but I must have been so blinded! Thanks for mentioning this, this is clear for me. But I have follow up problem with adjusting RTC:

I would like sync RTC clock to precise using SNTP timestamps (I have verified timestamps, received correctly, calculated time difference and remaining msec.

(1) When using LSE for RTC clock I can use RTC->SHIFTR to correct msec offset and (RTC tuned with 3-6 msec diff) (LSE = 32.768kHz, prescaller async = 127 & sync = 255 ) to produce 1Hz

(2) Firstly I tested with HSE clock and it was annoying me there... when selecting HSE for RTC clock ( 25 Mhz divided by 25 to make 1000kHz RTC clock source with async = 99 and sync 9999 (or tested also with async=124 and async=7999) I have still errors (after writing to RTC->SHIFTR it looks that subseconds is not tuned and their are hopping between hundred msec in their full range for example +172; +544; +260; +186; -271; -268). It looks that there could be something wrong with prescallers settings here.

 

Both codes are tested verified that RTC is ticking normally, and there are exactly same code except MX generated RCC settings and ASYNC/SYNC prescallers for RTC.

Do you have Ideas what could be wrong ? Or the HSE as clock input for RTC is not suitable for this task ?

Many thanks in advance for your help

Regards

Radim

>  it looks that subseconds is not tuned and their are hopping between hundred msec in their full range

Software error, not taking into account the changed synchronous prescaler properly in the shift amount calculation?

Try only *one* shift, noting down the deviation before the shift, amount of shift, and deviation after the shift.

JW

 

ravo
Senior

Dear @waclawek.jan 

I just tried to setup RTC time and msec only one-time after initialization (after first SNTP packet received) and then I only calculate differences (so without calling SET RTC time and HAL_RTCEx_SetSynchroShift )

I am attaching log of timestamps, offsets, etc... from both LSE and HSE, it is abou 15 seconds periodic

In LSE if I disable periodic synchronization, you can see cumulative difference (last column), and here if I turn periodic sync + shift it works ok.

But for HSE version, it look like that values are in waves, or saw... hard to say

Radim

Are you sure you are running from a crystal oscillator in the HSE case?

What hardware is this, exactly? What is the HSE arrangement?

JW

I suppose that it is running from 25 MHz :) I verified the HSE clock by scope using MCO output and is working fine.

I am using NUCLEO H755 board https://www.st.com/en/evaluation-tools/nucleo-h755zi-q.html

I solder xtal, capacitors and change SBxx resistors to adapt HSE instead of default clock 8MHz - STLK_MCO from STLINK. All periferials working normally, and ALARM on RTC produce 1sec interrupts. I am attaching both IOC files, and screenshot for quick verify

ravo_0-1733844980087.png

ravo_1-1733845052119.png

Radim

 

 

All that looks and sounds well, and I have no further ideas how to explain your observations, sorry.

JW

ravo
Senior

Dear @waclawek.jan 

Thanks for your comments. Do you think that this is not related to fact, that I don't have PREDIV_S non-zero multiple of 256 as noted in 49.3.16 Calibration clock output in TRM document:

"When COSEL is set and “PREDIV_S+1” is a non-zero multiple of 256 (i.e: PREDIV_S[7:0] =
0xFF), the RTC_CALIB frequency is fRTCCLK/(256 * (PREDIV_A+1)). This corresponds to a
calibration output at 1 Hz for prescaler default values (PREDIV_A = Ox7F, PREDIV_S =
0xFF), with an RTCCLK frequency at 32.768 kHz."



But I have here 30 pulses in 1 seconds with period * 32 ms + (at end one which is 16 ms positive pulse + 24 ms pause ) which correspond to TRM.

ravo_0-1733853342749.png

But I don't know if this could also affect SHIFTR. What do you think ?

Regards Radim

At this point, I'm confused what are you actually doing.

I thought you are reading out time including SSR to compare to SNTP timestamps; but now you brought out RTC_CALIB output. So which one is it?

The calibration output is probably an extra issue in itself.

JW