STM32 ADC readings are saturating, any thoughts?

[Rclar.13]

So we have just gone into production on a new design, a very small part of the circuit monitors the devices battery voltage fed into one of the ADC channels. I am finding that 1 in every 50 boards has developed a failure with the ADC where it just reads 0xFFF for this channel. The battery I am monitoring is divided down with a 1M potential divider, following that there is an unity gain buffer with a low pass filter on the output . The low pass filter is 470R and 100n. The battery is 4.2V to 3V and gets scaled down to 2.1-1.5V via the potential divider. my VREF+ pin is connected to an external 2.5V reference. My VDDA pins are filtered and connected to a regulated 3V and system GND. I can instrument the failed boards and all the signals external to the IC check ok ie VDDA, EXT_REf etc, input looks correct no spikes etc. The issue is solved by replacing the processor with a fresh one and the board works correctly. Any thoughts as to what is going on ?

[Uwe Bonnes]

I have seen STM32 damaged by overvoltage where the chip supply looks short circuit. I have seen ADC inputs pulling the measurement line high, probably also by ESD. Remeber also that 5-Volt tolerant inputs are often only 5-Volt tolerant with VDD applied. So wrong power sequencing may also damage your chip. Rething your setup and such possible problems.

[waclawek.jan]

Which STM32? Which pin?

> all the signals external to the IC check ok ie VDDA, EXT_REf etc, input looks correct

Also the pin in question is OK? I'd expect the protection diode to VDD to be shorted.

JW

[Rclar.13]

I have checked the pin in question it is ok, I get the correct voltage at the pin. I would also expect the protection diode to have shorted for the ADC to saturate. All the signals on the outside looked fine but the ADC data reg stubbornly reads 0xfff. Problem solved by changing the chip so I can only assume the processor is damaged in someway, either in handling the part or the finished board itself prior to test. We have seen this twice now in a pilot production run of 70 boards. My Production manager is happy as can live with the yield as long as it doesn't increase drastically. My view is I like explanation to help make future designs better.

[Ozone]

I remember a thread with a similar problem lately.

I think it was related to Vref being above VDDA, but might be wrong here.

Perhaps the issue is related to the power-on behaviour of the supply sources.

[Rclar.13]

Many thanks Uwe, Interesting thoughts, I can only imagine something like this is going on. I did some reading, maybe some reviewing the protection on the input ESD diodes may help. Issue I have is most of the products I work on are very small IOT so adding more components to the BOM is not exactly encouraged!

[waclawek.jan]

Which STM32? Which pin?

How is the opamp's power supply related to the mcu's one?

Is there any other channel measured by the ADC? Internal channels? Can you retain one of the faulty boards to try all other/internal ADC channels?

> The reference is only switched on a short time before making an ADC

Are you sure when the 0xFFF result was taken, this reference did switch on?

JW

[Rclar.13]

So its a STM32L4R5 in LQFP144 package with the voltage to be measured at Pin46 PB0 . Another analog measurement is made next door and pin47 PB1. The product has a DC 6-30V input and a nominally battery input , these are connected to a charger IC that provides a system voltage VSYS from either power source. The STM32 is regulated via an LDO to 3V from VSYS. The op amps that buffer the DC and battery voltages to be measured are supplied by VSYS. This is probably a mistake, they should probably be on the regulated supply (3.0V) too as there outputs will never be > 2.5V . Maybe this is causing some glitch that burns something out., just clutching at straws!

Either channel that is measured PB0 and PB1 both read 0xfff, I have not tried the internal channels (VINT and TEMP) I did not think VINT would be valid as I am using an external REF on VREF+. The reference is certainly powered up when the measurement is made. We only switch on the REF when we need to make measurement to save current but I hacked the code to enable the reference all the time. I can measure a clean 2V5 at the VREF+ but still 0xff from these channels. I ahve not other ADC channels wired up as the pins are used for other stuff, digital IO serial buses LEDS etc.

My only conclusion is that the STM32 is either damaged in handling or assembly or some other infrequent glitch occurs that damages that something.

[waclawek.jan]

PB0 is TT_la, but PB1 is FT_a. I somehow doubt both pins would be damaged in the same way, without impact on their behaviour externally.

But maybe the ADC mux/sampling cap got internally damaged. Doesn't much plausible to me though either.

Both channels read out as max can be explained also by inadvertent misconfiguration of ADC. Did you try reset/power down/up cycle or perhaps firmware reprogramming on the failed devices?

I'm not familiar with the L4+ but they are very complex in the analog part AFAIK. Can't ADC's reference be switched away from the physical VREF+ pin?

JW

[NVand.1]

Hi Rclar.13 and all,

I seem to be experiencing a similar issue. I am using an STM32L496ZG and during the test production run, we got 4 out of ~200 with saturating ADC measurements.

The only fix we have until now is replacing the CPU. In which case, everything is fine again.

The voltages at the input of the ADCs are measured as expected.

Rclar.13 what is the date code of the CPUs that are falling for you?

[Rclar.13]

Hello NVand.1 . This sound similar to me I was using a SMT32L4R5ZIT. The voltages at the ADC inputs are as expected but the readings are saturated. As you have mentioned replacing the cpu does fix it.

I am not sure how to find out the date code.

[NVand.1]

By the way, are you using the one with the external SMPS?