2025-03-20 11:39 AM
Started using PA2 pin as a ADC input and found that the input voltage get corrupted with LSCO output. Happens not always, but very often. Powering board down and up sometimes fixes the problem, sometimes not.
The LSCO output enable control bit LSCOEN is 0. Calling HAL_RCCEx_DisableLSCO() doesn't help.
Thanks,
George
Solved! Go to Solution.
2025-03-26 2:18 AM
Cube/HAL is open source, so you can always observe what do its function do - or what they don't.
For example, HAL_RTCEx_DeactivateCalibrationOutPut() uses __HAL_RTC_WRITEPROTECTION_DISABLE macro, but it does not perform the general backup domain enable through setting PWR_CR1.DBP, so its functionality depends on whether some surrounding/preceding code unlocks the backup domain and leaves it unlocked.
Nonetheless, you may want to follow the errata recommendation and upon suspected brownout perform a backup-domain reset before starting to configure RTC.
JW
2025-03-21 3:04 AM - edited 2025-03-21 3:15 AM
Maybe consequence of the backup-domain brownout erratum.
> The LSCO output enable control bit LSCOEN is 0.
Have you checked that by reading out RCC_BDCR when the error occurs?
JW
2025-03-24 8:59 AM
Thank you for responding.
I have tried the below calls in the SystemClock_Config() without a success.
HAL_PWR_EnableBkUpAccess();
__HAL_RCC_BACKUPRESET_FORCE();
__HAL_RCC_BACKUPRESET_RELEASE();
2025-03-24 9:38 AM
According to RCC_BDCR description:
[...] except the LSCOSEL, LSCOEN, and BDRST bits that are only reset upon RTC
domain power-on reset [...] [emphasis mine]
Nonetheless, have you tried to read out RCC_BDCR to make sure that this is the problem indeed?
JW
2025-03-24 2:11 PM
This is the BDCR register when PA2 is acting as a clock output.
2025-03-24 2:18 PM
Same BDCR when PA2 is not a clock output.
2025-03-25 3:47 AM
OK so LSCOEN is 0, which appears to indicate that the problem may have some other root than LSCO being active.
What makes you to say that PA2 is "acting as a clock output"?
What signal do you observe at PA2 and how do you observe it?
What hardware do you use, what is connected to PA2?
Read out and check/post content of GPIOA registers, for both "good" and "bad" states.
JW
2025-03-25 7:07 AM
In our design PA2 is used as an ADC input. Just recently started using and found a problem. Would be easier to use another pin, but boards are already in production.
The issue we found: every 500 ms the ADC value we are monitoring gets corrupted. The oscilloscope revealed the 1 Hz clock signal on the pin PA2: signal goes to zero; then 500 ms later back to its original analog value.
Resetting the microcontroller never fixes the issue; power cycling sometimes does.
2025-03-25 9:14 AM - edited 2025-03-25 9:15 AM
1Hz does not sound to me as LSE or LSI (both would be around 32kHz and presumably push-pull i.e. 0-3.3V).
Read out and check/post content of GPIOA registers, for both "good" and "bad" states. Try to stop the mcu at the moment when the signal is pulled to zero, before reading out those registers.
JW
2025-03-25 8:08 PM
Clarification. The 1 Hz appears to be on PA4 not PA2. I did some research and found out that this is the Calibration clock output that can be enabled with setting COE bit in RTC_CR.
The COE bit is set when PA4 is acting as output, and COE is reset when PA4 is working as expected.
Tried calling HAL_RTCEx_DeactivateCalibrationOutPut() at the end of MX_RTC_Init() without a success.