Error stm32G030 not specified in the errata file.

[PBobo.1]

When using RTC, the GPIO pin state of PA4 may be corrupted. RM0454, section 23.3.3 says:

"In addition, it is possible to output RTC_OUT2 on PA4 pin thanks to OUT2EN bit. This

output is not available in VBAT mode. The different functions are mapped on RTC_OUT1 or on RTC_OUT2 depending on OSEL, COE and OUT2EN configuration, as show in table

Table91.

For PA4, the GPIO should be configured as an alternate function."

But, as my experience has shown, RTC_OUT2 gets to PA4 even when PA4 is in mode GPIO OUTPUT. 

In addition, the RTC_CR_OUT2EN and RTC_CR_COE bits do not affect the operation of PA4 in any way. (See Table 91. RTC_OUT mapping)

In my case, RTC->CR was initialized like this:

RTC->CR =

3 << RTC_CR_OSEL_Pos | //Output selection: 0-disabled, 1-Alarm A, 2-Alarm B, 3-Wakeup

1 << RTC_CR_WUTE_Pos | //Wakeup timer: 0-disable, 1-enable

1 << RTC_CR_BYPSHAD_Pos; //0-values taken from shadow regs; 1-Bypass the shadow regs.

The effect of RTC on PA4 operation stopped when I changed the contents of the RTC_CR_OSEL field to 00:

RTC->CR =

1 << RTC_CR_WUTE_Pos |

1 << RTC_CR_BYPSHAD_Pos;

[KhPaul]

I don't have any issues with enabling RTC_OUT2; my problem is using it as an output when I'm not using it as an RTC output. I don't understand you at all - earlier you said you use your own library because LL is buggy, but now you're providing code with LL. How is this related to the problem? Let me repeat: when the RTC domain is enabled, PA4 stops working as an output but continues to work as both digital and analog input. There's no mention of this in the reference manual, and this is a serious issue, isn't it? Regarding the alternate function - I quoted ST's documentation. If it works without it, that doesn't mean it's correct. During development, we must strictly follow the documentation rather than the "it works anyway" principle, don't you think?

[eos1d3]

It is right that I said RTC LL library is buggy. I mean the whole RTC library is useless and has serious issues. But RTC_OUTx related functions are OK.

we must strictly follow the documentation rather than the "it works anyway" principle

---

Your expectation for ST documentations is too high. From what I read, their documentations are mixing with various older STM32 series and not updated to the new designs. The same peripherals in different series may work differently and they never refresh them in datasheets! 

STM32 is good. But their documentations are totally garbage. LL and HAL libraries never has official documentations. They just use tools to give you header summary which are machine generated junks. Unlike Nordic, their documentations are really pretty and well formatted.  

No need to say, STM32CubeIDE has serious bugs exists for years and they never fix them.

These are what ST offer. Use it or drop it.