When PWM output through TIM2 channel 1 on STM32G061G6U6 is enabled, the data register of ADC1 sometimes stores high values (~4095) even if there is no signal being fed to it.

[PIvan.9]

Here is the configuration I use:

int main(void)
{
  HAL_Init();
  SystemClock_Config();
  MX_GPIO_Init();
  MX_ADC1_Init();
  MX_TIM2_Init();
  
  // configure PWM
  __HAL_TIM_SET_AUTORELOAD(&htim2, 1000);
  __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, 1001);
  
  // start PWM
  HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1);
  
  // configure ADC
  HAL_ADC_MspInit(&hadc1);
  // start ADC in interrupt mode
  HAL_ADC_Start_IT(&hadc1);
 
  while (1)
  {
  // some code
  }
 
// callback for ADC interrupts
void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc)
{
  // some code
}

When lines 11 and 14 are not commented out (i.e. compare register is configured and PWM is enabled), the ADC1 sometimes reads high values with no signal being fed to it (ADC input pins are pulled down, so there is no floating voltage). When lines 11 and 14 are commented out, there is no such issue. Also, by changing the TIM2 PWM channel to any other one, the issue dissapers. This was tested on 2 MCUs.

Does anyone have any ideas why TIM2 channel 1 PWM might interfere with ADC readings?

[PIvan.9]

Yeah, but there is no dev board with exactly STM32G061G6U6 chip.

[PIvan.9]

Yes, you're right about HAL_ADC_MspInit(). I've attached my project to this message.

On my board I also disconnected PWM output pin (PA0) from the rest of the circuit and as I mentioned previously, ADC input (PA2) is tied to ground.

[Philippe Cherbonnel]

Hello @PIvan.9​ ,

Thanks for your whole CubeIDE program.

I have tested it on a board Nucleo STM32G070RB (device similar to STM32G061): I do not reproduce your issue.

Even after even after 30min run, I never go in case of ADC conversion saturated high.

I have checked low frequency mode, in case of triggers spaced out of more than 100us for STM32G0.

Conversion duration:

In your configuration, ADC clock from PLL-P 16MHz with prescaler 10, sampling time 1.5 ADC clock cycles, resolution 12 bit:

Tconv = Tadc_clk * (Tsmpl + Tsar) = (1/ (16MHz / prescaler 10)) * (1.5 + 12.5) = 8.75us

So it's ok for setting TriggerFrequencyMode = ADC_TRIGGER_FREQ_HIGH;

Can you try to increase sampling time, for example to 39.5 ADC clock cycles ?

(but low probability of the root cause since you have tested with ADC channel grounded)

What could explain the random behavior on your side ?

The board environment could be the cause: for example, some instabilities on voltage reference Vref+.

(on STM32G061G6U6, pin Vref+ available with package LQFP48 or connected to pin Vdda on other packages).

The link with PWM would be strange, but side effects due to current draw are possible.

Is there a stable voltage supply, decoupling capacitor, ..., on your board ?

You can refer to application note:

AN2834: How to get the best ADC accuracy in STM32 microcontrollers

As suggested by @Community member​ , you can compare you board design and program execution on a known good board with similar devices: STM32G071 or STM32G070 Nucleo/Eval (as STM reference design).

Best regards

Philippe

[PIvan.9]

Hi Philippe,

Thanks for your time and trying to help.

So far, I've figured out that the false values the ADC stores in its data register are all equal to exactly 4095. I've double checked that the ADC inputs are not connected to anything other than GND and I've also measured them with oscilloscope, they are actually at 0V as expected.

The only way I can check ADC readings is with if condition and GPIO toggling, since I don't have any communication protocol connection (I2C, UART, SPI) on my board.

After setting up oscilloscope, it looks like most of the readings are the false ones and the one that should have a proper low value appears once in 8 readings. See the graph below, yellow line is pin toggling at values 4095, blue is another pin toggling at values lower than 500.

Changing sampling time only affects the period between readings/pin toggling, but it doesn't fix anything.

I don't have any explanations for this behaviour from my side, since power supply is designed properly in my opinion. Also, bad supply wouldn't explain why this issue appears only during enabling PWM output on one specific channel and disappears when a channel is changed to another one. Also, I don't think that the current draw can be the reason, since PWM pin is disconnected and duty cycle is set to 100%.

Regards,

Pavels