2020-09-10 07:17 AM
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...
Solved! Go to Solution.
2020-09-15 02:10 AM
Why 50Hz
2020-09-15 02:13 AM
From the measured waveform: the resolution is not 6-bit like. There are also finer steps (less than 52mV). It looks like there is problem with ADC linearity - the incorrect waveform has period of incorrect behavior for each step od 3300mV / 8 = 412.5mV. The behavior is like very poor decoupling of the VREF+ (which is not true = because Nucleo board is not so bad). Or the ADC clock is very high - but the code is correct: ADC clock is set to frequency SYSCLK / 4.
Can you please perform experiment with lower ADC clock - either by using lower SYSCLK or using lower ADC clock.
I hope that there is no problem with DAC. Can you please use some ADC buffer instead of sending data to DAC output and then check the waveform in this buffer - if waveform in ADC buffer it is also incorrect.
Regards
Igor
2020-09-15 02:19 AM
I reduced the ADC clock (system clock) to 160MHz, the measurements look fine now. I need to find the root cause now.
2020-09-15 02:26 AM
And how speed is your timer trigger plus have you continuos mode enabled or disabled for ADC...
2020-09-15 03:29 AM
Continues mode is disabled and timer trigger is 1.5uS. But I tried with 200uS and the same result.
2020-09-15 03:30 AM
Lower clock speed helps. At 160Mhz instead of 170Mhz the sampling looks fine.
I checked buffer instead of DAC before. It isnt the DAC, but the ADC who causes the issue.
2020-09-15 03:34 AM
I changed system clock back to 170Mhz and the PLL to clock/3 = 113Mhz.
It works fine. However, I'm concerened about the root cause and would like to use this solution only in absolut worse case.
2020-09-15 03:46 AM
Seems as any sw or hw issue break ADC conversion in execution and resulting is only 6bit (pooling fail), I recomend use fine values for all parameters not extreme.
Sampling 1kHz with 666kHz is waste of resources, too sampling 6.5 cycles is extreme use more is better for handle charging ADC circuit.
And as last better is use EOC irq or dma as pool wait.
2020-09-15 04:54 AM
The original code uses DMA pool, the here used debug code is a simple as possible code, to avoid any sw related issue.
I use the 6.5 cycles, because thats the sampling of the original code, but I tried more cycles already without improvement.
In original code I can't reduce the sampling cycles, due to the necessity of very fast signal sampling. I would use 2.5 cycles, but the results arn't as good as 6.5 cycles. This equals to 38ns. More than 100ns are for this application not acceptable anymore.
In this example I used a signal of 1kHz, but in the real application we will measure a sine wave with 250kHz frequency. Here you can't do a slow sampling anymore.
2020-09-15 05:32 AM
Thank you to everyone who was helping and supporting. The issue is closed.
Here the findings and root cause: