Issue with AD conversions

[DBein]

We encountered a big issue with the ADC's in a project.

The G4 device has 4 ADC's configured (ADC1, ADC2. ADC3, ADC5).

ADC1 and ADC2 are sampled simultanious and triggered by HRTIMER1A interrupt with 4 channels each.

ADC3 and ADC5 are in independent mode and are triggered at different times by HRTIMER1B interrupt with 1 channel each.

The problem we encountered now is that the ADC1 samplings are not consistent.

It seems like there are always "steps" on which the measured voltages stay or alternate.

First I assumed some problem with the ADC multiplexing, however after disabling all but ADC1 the issue is still there. The signals at the ports are all fine and stable without noise, the Vref is external but stable as well as Vcc. It somehow looks like the ADC got damaged. I tested the same code on a Nucleo board with the same result. We got like 20 PCB baords, all use the same code, but about a third of the boards are messed up. Another weird thing is, that the ADC measurements and "steps" are getting much worse with increasing temperature.

We need urgent help...

[DBein]

​After further testing we found that the ADC is working only with 6-bit resolution. However, it is configured as 12-bit ADC and the register gives us 12-bit results.

The sample results are the same for the 12-bit ADC setting and the 6-bit ADC setting (after shifting the 6-bit result by 6).

I tested the oversampling function and it will improve the ADC measurements.

Seems like for some reason, that one third of our G4 devices are only operating with 6-bit resolution (in 12-bit mode) and the other two third of the devices are okay.

Currently I'm debugging on a Nucleo board and I try to get another ASAP to verify the results.

BTW, I'm using a simple CubeMx generated code with only one ADC, which is triggered by software during a timer interrupt, to make sure that the issue is not caused by any weird device setup.

Please advice...

[Uwe Bonnes]

Check VDDA, VREF, soiurce impedance and sampling time. Best is you test with a much simpler ADC setup first. Your results make me think ,there is a problem in your setup.

[DBein]

​VDDA is stable, Vref is stable (might be something to do with it though), source is a signal generator and a poti, sampling time I changed from 6.5 cycles to 247.5 cycles with no impact on the result.

Current setup is only one ADC with software trigger during timer interrupt.

[DBein]

​It doesn't matter if internal or external VREF. The result stays the same.

[Igor Cesko]

My first check of firmware:

In the TIM17 ISR is there no waiting for ADC EOC event (end of conversion). There is only start of ADC conversion and in next is there reading of the ADC without checking if conversion is already finished:

TIM17 ISR code:

/**
  * @brief This function handles TIM1 trigger and commutation interrupts and TIM17 global interrupt.
  */
void TIM1_TRG_COM_TIM17_IRQHandler(void)
{
  /* USER CODE BEGIN TIM1_TRG_COM_TIM17_IRQn 0 */
  
  static float f32AdcValueFlt;
 
  HAL_ADC_Start(&hadc1); //                                                   <-- start of ADC
 
#if 0
  f32AdcValueFlt = ((0.9F * f32AdcValueFlt) + (0.1F * HAL_ADC_GetValue(&hadc1)));
  DEBUG_SECTION_DAC1_CH1(f32AdcValueFlt);
#else
  DEBUG_SECTION_DAC1_CH1(HAL_ADC_GetValue(&hadc1)); //                        <-- immediately reading of the ADC
  //DEBUG_SECTION_DAC1_CH1((HAL_ADC_GetValue(&hadc1)) << 6);
#endif
  /* USER CODE END TIM1_TRG_COM_TIM17_IRQn 0 */
  HAL_TIM_IRQHandler(&htim17);
  /* USER CODE BEGIN TIM1_TRG_COM_TIM17_IRQn 1 */
 
  /* USER CODE END TIM1_TRG_COM_TIM17_IRQn 1 */
}

Please add before the ADC reading check for EOC event: by function:

HAL_StatusTypeDef HAL_ADC_PollForConversion(ADC_HandleTypeDef *hadc, uint32_t Timeout)

or by some faster check for EOC.

Regards

Igor

[DBein]

void TIM1_TRG_COM_TIM17_IRQHandler(void)
{
  /* USER CODE BEGIN TIM1_TRG_COM_TIM17_IRQn 0 */
  HAL_ADC_Start(&hadc1);
  HAL_ADC_PollForConversion(&hadc1, 10);
  DEBUG_SECTION_DAC1_CH1(HAL_ADC_GetValue(&hadc1));
  //DEBUG_SECTION_DAC1_CH1((HAL_ADC_GetValue(&hadc1)) << 6);
  //HAL_ADC_Stop(&hadc1);
  
  /* USER CODE END TIM1_TRG_COM_TIM17_IRQn 0 */
  HAL_TIM_IRQHandler(&htim17);
  /* USER CODE BEGIN TIM1_TRG_COM_TIM17_IRQn 1 */
 
  /* USER CODE END TIM1_TRG_COM_TIM17_IRQn 1 */
}

I added the polling for EOC/EOS, but no change. In the original code I use DMA, so I dont think this is the problem, however you are right, it has to be added.

[Singh.Harjit]

This may not be the issue: There are at least two versions of the STM32G4 silicon and on the original version, changing channels caused corruption. Check the Errata for details.

[DBein]

​I checked the errata for the issue and did try the workaround, however it didn't solve the problem. We also changed the code to one channel with one ADC. The problem stays there. I'm not sure if something got damaged. I'm waiting for a new MCU to do a re-test.

Will check the simple code first, then use the complex code and change back to the simple version. I wonder if it will have some impact on the behavior.

[Igor Cesko]

I have tried to reproduce the problem - but I see no incorrect behavior - results are always 12-bit wide. probably I have all samples "correct". I will ask for another samples to recheck again.

Do you have all samples from the same lot?

Regards

Igor