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;

[Sarra.S]

Hello @PBobo.1 

Thank you for your input,

In this case, configuring GPIOs (PA4, PC13) as alternate functions is the same as configuring GPIO in output mode, this note in the ref man (and the Cube examples) is there so users won't configure GPIO as input or analog... 

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

Please correct me if I'm wrong, but you're talking about this case?

[PBobo.1]

>>...this note in the ref man (and the Cube examples) is there...
Please point out where in the reference manual this is mentioned. Or provide a quote.

>>Please correct me if I'm wrong, but you're talking about this case?
For the case you indicated in yellow in the table, GPIO works correctly, PA4 is controlled by GPIOA->ODR.
Incorrect operation of GPIO PA4 is observed when the field RTC_CR_OSEL=11, RTC_CR_OUT2EN=0 and RTC_CR_COE=0.
In this case, PA4 should work as a GPIO, but in fact some signal from the RTC goes there.
At the same time, there is a strange voltage level of 1.9 volts at pin PA4. (Controller power supply is 3.3 volts.)

[Sarra.S]

Hello @PBobo.1 

I tried what you have suggested (RTC_CR_OSEL=11, RTC_CR_OUT2EN=0 and RTC_CR_COE=0) 

I tried toggling PA4 when masking RTC_CR_OSEL to 11, the GPIO is toggling normally with 3v3 voltage level. 

Could you please provide the FW to reproduce the issue, also "some signal from the RTC goes there", how did you visualize that, could you try and toggle the GPIO under those conditions (RTC_CR_OSEL=11, RTC_CR_OUT2EN=0 and RTC_CR_COE=0) and probe it with a LA and share the results! 

I'm looking forward to your response

Thank you 

[waclawek.jan]

Hi @PBobo.1 ,

Have you been able to reproduce the problem or identify its root cause?

Thanks,

JW

[eos1d3]

---

@PBobo.1 wrote:

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

This is because STM32CubeIDE/STM32CUBEMX generates code to enable RTC_OUTx if you want to enable it. But if you does not want it, the generated code does not contains code to disable RTC_OUTx. So RTC_OUTx is still enabled because they are VBAT domain.

What you have to do is:

1. User code to disable it, or

2. Power reset (no VBAT supply)

PS: ST RTC library is extremely buggy. For example, 1 second delay for each programming. Using LL libraries cannot enable RTC_OUTx because RTC write is disabled by the generated code. And they are many other bugs. So I use my own library.