Associate II

Solved

Issue with AD conversions

Forum|Forum|5 years ago
September 10, 2020
32 replies
5956 views

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...

This topic has been closed for replies.

Best answer by K.Oku

Hello.

We already have conference call to discuss this problem.

It was identified that ADC clock was set to 170MHz, but ADC clock speed max is 60MHz. Due to this, ADC shows missing codes, etc.

By reducing ADC clock, it should solve the problem.

We also discussed that older version of CubeMX does not flag the wrong ADC clock setting.

Newer version of CubeMX will flag the wrong ADC clock setting(Or cannot select higher frequency than the spec).

DBeinAuthor

Associate II

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

Chief

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.

DBeinAuthor

Associate II

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.

DBeinAuthor

Associate II

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

Igor Cesko

ST Employee

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

DBeinAuthor

Associate II

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

Senior

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.

DBeinAuthor

Associate II

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

ST Employee

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

DBeinAuthor

Associate II

Did you use the code I send earlier?

Not all of our samples are from the same lot. But the ones we use in our design should be from the same.

Unfortunately I'm not in office today, but tomorrow I can continue testing on a second Nucleo board.

I will update you ASAP.

Igor Cesko

ST Employee

I used your simple code - one ADC converted in timer interrupt and result is sent to DAC output. I have monitored the DAC output (by oscilloscope) for large steps (like for 6-bit resolution). But I see always very smooth waveform (as ADC input is triangle waveform with small amplitude to see the steps on the oscilloscope: one step for 6-bit resolution is ~52mV). I tried several samples with no problem.

Regards

Igor

Igor Cesko

ST Employee

You wrote that results are worse by increasing temperature. What does mean worse? You reported that the result is only 6-bit wide. What happens if temperature is increased? Does the result become more incorrect (more bits are missing)? Or are there some another devices which started to have only 6-bit results? What temperature is reached?

Thanks for information.

I had used for testing the simple code you have sent.

Igor

DBeinAuthor

Associate II

When increasing the temperature, the 6-bit ADC steps stay the same, but the measurements start to toggle more frequenctly between two steps.

However, this isn't of priority now. We need to get the full 12-bit resolution.

It is good that you tried the same code, that means it is not code related.

I fear that it is either related to having an older device revision or some setup issue.

We probably could send one of our boards where we observe the issue to you for further investigation, but I will set up another bench first, to verify my results.

I plan to have a call with you guys later if we can't fix it before.

DBeinAuthor

Associate II

I used a second Nucleo board with the same code that I send before.

I still get the weird 6bit ADC resolution. We are waiting now for new Nucleo boards and some new MCU's from ST.

Is it possible to get a code example from your side, which you tested and verified on a Nucleo board before?

Code requierements would be:

At least one ADC channel sampling with 12-bit on ADC1
One DAC in 12-bit mode for displaying the sampled channel
Timer interrupt for managing the ADC and DAC

Then I would be able to confirm if the problem is code related or somehow from our hardware / setup.

DBeinAuthor

Associate II

This one is unnesseary now, since you verified the test code already.

Show more replies

Sign up

Login with SSO

Login to the community

Login with SSO