Dear Team,
R7FS5D57C3A01CFP MCU- is used.. We are experiencing a problem with the RTC in one of our products. When we set the RTC, there is no drift, and it counts correctly; however, two issues occur:
We have verified that there is no issue with the crystal; the frequency measurements are shown in the images below. Despite this, we replaced the crystal, but the issue still persists.
I would appreciate your help in understanding the cause of this issue and finding a solution. Thank you.
Best Regards
Hello,
RCR2.HR24 bit must be 1 for 24-hour mode
This fault is seen only one product. The other MCU's RTC is working well with same software. Could you suggest any register to readfor MCU is broken or other issue? How can I found reason this fault?
Best Regards.
Can you check this bit on the device which is not working ?
Hello, How can i check this register? When I add breakpoint to this function, the IDE didn't stop this driver's codes. Is there any other ways to control HR24 register value?
__STATIC_INLINE uint8_t HW_RTC_Counter24HourGet (R_RTC_Type * p_rtc_reg){ return p_rtc_reg->RCR2_b.HR24;}
Just put a breakpoint after RTC_open function and search for the register on the 'IO Registers' window of e2studio.
Thank you for your help. I checked the HR24 register with your method. As shown in the below picture HR24 register equal to 0.
But HR24 equals to 1 on the device which RTC is working correctly with same software.
In the RTC driver side HR24 sets to 1 as you can see in the code.
Why register did not change?
/*******************************************************************************************************************//** * Set the 24 hour mode**********************************************************************************************************************/__STATIC_INLINE void HW_RTC_Counter24HourSet (R_RTC_Type * p_rtc_reg){ p_rtc_reg->RCR2_b.HR24 = 1;
}
Is this option set to 'Yes' ?
It is currently set to "No" in the configuration.
What is the required configuration?
If this is set to Yes, the RTC registers and clock source will be initialized in the open() function. If it is set to No, you must call the configure() function to initialize them.
If it is set to No and you do not call the configure() function, some RTC register bits (like RCR2 bits) may have undefined values because they do not have a fixed reset value:
After I changed the Configure "RTC hardware in open() call" value to "Yes" as you said, the battery that I was getting an error about (HR24) and could not set the value to '1' has been fixed. It is currently working in a 24-hour time frame.
Thank you very much for your help on this issue.
But there are some things I want to ask because I don't understand.
1) I perform the open and configure process because the "RTC hardware in open() call" value is "No" in the current software. But why could not the proper configuration be done on only 1 battery?
2) We have not seen this error in more than 100 batteries we have used before. Is there a possibility that this error is product-based, i.e. hardware-related?
3) What is the configuration value that you recommend? Is there anything recommended? For example, not leaving the configuration to the user and setting it exactly as it should be.
4) Finally, when I set the "RTC hardware in open() call" value to "Yes", the START bit of the RCR2 register is 0. But when it is set to "No", it is seen to be '1'. What could cause the difference between the two cases?
Driver's Codes
__STATIC_INLINE void HW_RTC_Counter24HourSet (R_RTC_Type * p_rtc_reg){ p_rtc_reg->RCR2_b.HR24 = 1;
This function call in open api and I also call the open api in RTC initialize function.
As mentioned if the value in an RTC register after a reset is given as x (undefined bits) in the list, it is not initialized by a reset. When RTC enters the reset state or a low power consumption state during counting operations, for example while the RCR2.START bit is 1, the year, month, day of the week, date, hours, minutes, seconds, and ***-Hz counters continue to operate.
So the option should be configured according to the user application
When the "RTC hardware in open() call" value to "No", the following if-statement will not be executed:
The r_rtc_set_clock_source function clears START bit to 0 and sets the hour mode bit:
It is a bit strange the problem is this one device, but does every RTC API return with SSP_SUCCESS ?
We have not seen this error in more than 100 batteries we have used before. Is there a possibility that this error is product-based, i.e. hardware-related? Other MCU's HR24 is 1 from the beginning. Is there any possibility HR24 register sets 0 during mass production. If the configuration section is selected to yes to change HR24, will we see a problem related to rtc working?.
I check the RTC API return values. The RTC APIs and responses used in the initialize section are shared in the picture below. I think there is no problem in the API values.
What SSP version do you use ?
Does this error still happen ?
Is the above code with the option set to Yes or No ?
If you set this option to 'Yes', the only thing that it changes is that the RTC clock source and registers will be initialized every time after reset. Is this a problem for you ?