Stabilizer MCU internal ADCs show an offset error. about stabilizer HOT 14 CLOSED

Some things I currently don't understand:

• Setting the sampling time lower seems to make the values more accurate. With 2.5 ADC cycles sampling time the values are bang on. With 8 cycles the values are about 1 % off and for >16 cycles they are ~ 2-3 % off.
• The default sampling time should be 1.5 ADC cycles since this is the reset vaue and the respective register is not written in the adc startup of the hal driver. But if I don't set another sampling time the values read low as observed with longer sampling times.

from stabilizer.

More observations:

• The sampling time has a strong effect on linearity. A short sampling time leads to a massive error at both ends of the dynamic range.
• With a long sampling time there seems to be little non-linearity but a constant offset of about -0.03 V.

from stabilizer.

Pin leakage current should be less than 1 uA. 2K external resistance cannot account for the offset and I also measured the voltage on the capacitor right on the pin.

from stabilizer.

I've now thoroughly checked that 25.4.8 Calibration is followed. The only thing that is not explicitly checked is the that the LDO is ready, which can only be checked on some device revisions apparently. I inserted an extra second of delay right before starting the calibration and it makes no difference so I think the LDO is not the problem.
Therefore I can't find a fault in the HAL's calibration routine.

from stabilizer.

I should also mention that not performing the calibration leads to an offset of about the same magnitude but in the positive direction.

from stabilizer.

I seem to have found the culprit. A slower (10 MHz) ADC clock leads to very accurate samples on all channels with a long sampling time.
I didn't yet find anything in the datasheet/errata about this. The 100 MHz clock used before should have been OK for chip rev V.

from stabilizer.

Hmm... Changing the ADC clock results in a different S&H interval, so it seems like the S&H time that we had previously may have been too short to sufficiently sample the input signal and bring the hold capacitor up to charge.

from stabilizer.

Yeah I'm not 100% certain about all the variables here but changing the sampling time (the time the S&H cap is charged) only had an effect at very small values (1-8 ADC cycles). So it seems to be disconnected from the ADC clock freq problem.

from stabilizer.

Actually the datasheet specifies a max freq of 50 MHz for the ref. V version afaict. I'm not sure why comments and the value for checking in the HAL suggest that it should work up to 100 MHz.
I also played around with different BOOST settings and those seem to have a great impact on accuracy at 100 MHz, again suggesting that the problem has to do with the maximum clock rate.

from stabilizer.

Ok, the current state is, that there is another factor of 1/2 in the clock path, so the 100 MHz max from the HAL might be valid in some cases. However, since a slower clock solves the issue I currently select another, slower clock input at the MUX.
I wasn't able to set the clock prescaler in the ADC because this is always reset during ADC init and cannot be set after.

from stabilizer.

The way the HAL is built right now the clock prescaler has to be changed after the adc initialization and befor the adc is enabled. Then, after changing the prescaler and before enabling the adc, the adc has to be re-calibrated.

from stabilizer.

The RCC specifies maximum frequencies for the ADC clock input as either 40 or 80 MHz depending on the VOS setting as well. If we're using 100MHz for the source, we're violating maximum timing requirements here.

from stabilizer.

I have in Rev 6:

@nkrackow in any case this is then a bug in the hal as it allows for 100 MHz.

from stabilizer.

closed by #584

from stabilizer.