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]

​Short description of my test setup:

I use a functiongenerator and generate a sine wave with 1kHz and feed it directly to the PA0 pin.

Pin PA4 is connected to buffered DAC1CH1 and feeds back the measured voltage.

[MM..1]

I dont see code, what you use but some mistake must exist. As first how amplitude have your generator ? Realy use full range of AD and how DC offset.

Second how type parameter use DEBUG_SECTION_DAC1_CH1 ( ?) . 3.how big is ADC clock/speed/sample time vs out impedance of generator eq dB down...

I check your scoped graph and here isnt 1kHz but 50Hz

[DBein]

​1. Signal generator amplitude is set to 1.3V and DC offset is 1.5V.

2. The DEBUG_SECTION_DAC1_CH1 macro only points to the DAC data register. This is working fine, I tested it with several waveforms generated by MCU itself.

3. ADC clock speed is 170MHz and sampling time is 6.5 cycles, but I tried 247.5 cycles with no improvement. Impedance shouldn't be the issue, the problem exists even when appliying variable DC signal.

[MM..1]

Why 50Hz

[Igor Cesko]

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

[DBein]

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

[MM..1]

And how speed is your timer trigger plus have you continuos mode enabled or disabled for ADC...

[DBein]

​Continues mode is disabled and timer trigger is 1.5uS. But I tried with 200uS and the same result.

[MM..1]

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.

[DBein]

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

[DBein]

​Thank you to everyone who was helping and supporting. The issue is closed.

Here the findings and root cause:

• Old CubeMx version was used to generate clock configuration and an inacceptable configuration was applied
• ST could reproduce issue after increasing clock speed to 170Mhz while ADC max clock speed is 60MHz
• New CubeMx version is removing option of wrong clock setting

[MM..1]

Then ok , but as i write an hw or sw issue break 6.5 cycle in middle and ADC dont work properly, i cant say why, but some conditions must be fail. When this break ocurs your changes to other numbers of cycles is irelevant. ARM is risc architecture and sometimes need special asm for working properly.

[DBein]

​Thats right, so it should be ensured that nothing will interrupt the ADC samplings.

Injected mode has to be used carefully as I know, I do use circular sampling currently without interruption.

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