Dear ST experts,
we're currently struggling with getting acceptable ADC performance with some of our samples of the STM32H753VIT ADC2. Our setup includes:
- ADC2 works in Independent mode
- using Scan Conversion Mode, 7 Channels (3, 5, 9, 10, 15, 18, 19)
- 14-bit resolution, 16x oversamplig (each channel), 2 bit right-shift for oversampling
- ADC2-Clock is 37,5 MHz, generated by PLL2P, before internal division by 2, Asynchronous clock mode divided by 1
- Continuous Conversion Mode and Discontinuous Conversion Mode are both disabled
- TIM15 triggers ADC2 every 100 µs to scan all channels
- DMA Circular Mode
- VRef = 3.0 Volt, external
- We set up a minimal STM CubeIDE project to verify the described behaviour
While more than half of our parts work more or less as advertised, but with some parts we reproducibly fail to generate decent calibration values; regardless of whether we use the factory-load linear calibration values (by using
HAL_ADCEx_LinearCalibration_FactorLoad(&hadc2);) or doing a self-calibration with
HAL_ADCEx_Calibration_Start(&hadc2, ADC_CALIB_OFFSET_LINEARITY, ADC_SINGLE_ENDED);
For testing, we use to apply a slow (1Hz) ramp signal to ADC2 channel3 while the ADC is running, buffer a large number of results in memory, stop the ADC when the buffer is filled, and finally read out the buffer via UART.
From the recorded ADC values, we cut out one ramp, and subtract the linear trend line. With the "bad" STM32H752 samples, we always get rather big jumps in the error curve, like this one:
Notably, the jumps seem to occur at multiples of 0x2000. So, we concluded that the calibration for the bit weights does not work properly with these examples.
Our main application is to accurately sinusodial signals around 0x8000, which gets ugly whenever the amplitude is small (because we then work in a small interval around the main dicontoninuity at 0x8000)
When investigating the issue, we have read out both the factory calibration value, and the linear calibration values resulting from self-calibrating, and noticed that all 10-bit-parts of the 160-bit linearity calibration factor lay around 0x200 (+/- roughly 0x1B). We conjectured that 0x200 may be a "neutral" value, and manually set all 10-bit-parts to 0x200:
uint32_t lincalbuf[ADC_LINEAR_CALIB_REG_COUNT] = {
0x20080200u,
0x20080200u,
0x20080200u,
0x20080200u,
0x20080200u,
0x00000200u,
};
HAL_ADCEx_LinearCalibration_SetValue(&hadc2, lincalbuf);A bit surprisingly, this gave us much a more "continuous" error curve, with all our parts ("good" and "bad"), e.g.
Thus we have a few questions:
i) Can someone tell us what is exactly the meaning of the 10-bit parts of the linear calibration factor, preferably with some formulae? By experimenting, we concluded, that the lower eight 10-bit parts represent the bit weights of the upper 8 ADC bits. Is this correct?
ii) Did we miss something when calibrating the ADC, which may explain the bad behaviour with some parts?
iii) Are there some risks when we use our "manual" calibration values (16 times 0x200) that we may not be aware of?
Best Regards,
Lukas Rauber
Hmm, good point.
My STM32H753 are already the (newer [?]) hardware revision "V". The differences that I found are:
- revision "V" hat two instead of one BOOST bits in the CR register, and
- revision "V" features a fixed internal ADC clock divider (by 2).
The BOOST bits are '0b10' in my setup; as I read the datasheets, this should be okay for my ADC clock of 37.5 MHz (before internal "/ 2" division), i.e. 18.75 MHz after the divider...
Following your advice, I tried a manual "bit-banging" self-calibration, as described in the reference manual, and also checked the CR register after calibration.
But sadly, no changes in the measured data. Here is the code and the output for the curious folks:
static ADC_HandleTypeDef * const padc = &hadc2;
static void calibrate_adc(void)
{
ADC_TypeDef * const adc = padc->Instance;
/* 1a) Ensure DEEPPWD=0, ADVREGEN=1. */
uint32_t reg = adc->CR;
reg &= ~0x3Fu; // don't set "rs"-bits
reg &= ~(1ul << 29); // disable Deep-power-down
reg |= (1ul << 28); // enable ADC Voltage regulator
adc->CR = reg;
/* 1b) Verify that the ADC voltage regulator startup time has elapsed. */
while (((reg = adc->ISR) & (1ul << 12)) == 0)
uprintf("# ADCCalib: waiting for ADC voltage regulator startup."
" ISR = 0x%08X\n", reg);
/* 2a) Ensure that ADEN == 0. */
reg = adc->CR;
reg &= ~0x3Fu; // don't set "rs"-bits
reg |= (1ul << 1); // set ADDIS bit
adc->CR = reg;
while (((reg = adc->CR) & 0b11u) != 0b00)
uprintf("# ADCCalib: waiting for ADC to turn off. CR == 0x%08X.\n",
reg);
/* 3) Select the input mode for this calibration, and
* select if Linearity calibration enable or not. */
reg = adc->CR;
reg &= ~0x3Fu; // don't set "rs"-bits
reg &= ~(1ul << 30); // disable ADCALDIGG (single-ended input mode)
reg |= (1ul << 16); // enable calibration *with* Linearity calibration
adc->CR = reg;
/* 4) Set ADCAL = 1. */
reg = adc->CR;
reg &= ~0x3Fu; // don't set "rs"-bits
reg |= (1ul << 31); // set ADCAL bit
adc->CR = reg;
/* Wait until ADCAL == 0. */
while (((reg = adc->CR) & (1ul << 31)) != 0)
uprintf("# ADCCalib: waiting for ADCAL == 0. CR == 0x%08X.\n", reg);
}
/* In main(): */
// ...
calibrate_adc();
uprintf("# INFO: ADC_CR register reads 0x%08X.\n", (unsigned)padc->Instance->CR);
dump_calibration_values("ADC_Calib_BitBang", 0);
uprintf("# INFO: ADC_CR register reads 0x%08X.\n", (unsigned)padc->Instance->CR);
// ....
# @startup
# Offset (single-ended): 0x0
# LinearCalib[ 0] (rv 0): 0x0
# LinearCalib[ 1] (rv 0): 0x0
# LinearCalib[ 2] (rv 0): 0x0
# LinearCalib[ 3] (rv 0): 0x0
# LinearCalib[ 4] (rv 0): 0x0
# LinearCalib[ 5] (rv 0): 0x0
# LinearCalib[ 6] (rv 0): 0x0
# LinearCalib[ 7] (rv 0): 0x0
# LinearCalib[ 8] (rv 0): 0x0
# LinearCalib[ 9] (rv 0): 0x0
# LinearCalib[10] (rv 0): 0x0
# LinearCalib[11] (rv 0): 0x0
# LinearCalib[12] (rv 0): 0x0
# LinearCalib[13] (rv 0): 0x0
# LinearCalib[14] (rv 0): 0x0
# LinearCalib[15] (rv 0): 0x0
# ADCCalib: waiting for ADC to turn off. CR == 0x10000203.
# ADCCalib: waiting for ADCAL == 0. CR == 0x90010200.
# ADCCalib: waiting for ADCAL == 0. CR == 0x90010200.
# INFO: ADC_CR register reads 0x1FC10200.
# ADC_Calib_BitBang
# Offset (single-ended): 0x3ee
# LinearCalib[ 0] (rv 0): 0x203
# LinearCalib[ 1] (rv 0): 0x205
# LinearCalib[ 2] (rv 0): 0x207
# LinearCalib[ 3] (rv 0): 0x20e
# LinearCalib[ 4] (rv 0): 0x211
# LinearCalib[ 5] (rv 0): 0x221
# LinearCalib[ 6] (rv 0): 0x211
# LinearCalib[ 7] (rv 0): 0x202
# LinearCalib[ 8] (rv 0): 0x204
# LinearCalib[ 9] (rv 0): 0x204
# LinearCalib[10] (rv 0): 0x20d
# LinearCalib[11] (rv 0): 0x20d
# LinearCalib[12] (rv 0): 0x216
# LinearCalib[13] (rv 0): 0x21d
# LinearCalib[14] (rv 0): 0x20a
# LinearCalib[15] (rv 0): 0x202
# INFO: ADC_CR register reads 0x10010201.
0x0809
0x0810
0x0820
0x0824
0x0828
0x082d
0x0834
0x083b
0x0841
[... more ADC values...]The data look as ever:
@MasterT wrote:What I usually do, is checking specific reg to make sure:
ZI2:
Reg: 5C001000 0010 0000 0000 0011 0110 0100 0101 0000 (0x20036450)
Bits 31:16 REV_ID[15:0]: Revision
0x1001 = Revision Z
0x1003 = Revision Y <----
0x2001 = Revision X
0x2003 = Revision V
Bits 15:12 Reserved, must be kept at reset value.
Bits 11:0 DEV_ID[11:0]: Device ID
0x450: STM32H742, STM32H743/753 and STM32H750
Both the device marking and the DBGMCU_IDC register indicate I have Hardware Revision 'V'.
@MasterT wrote:" The BOOST bits are '0b10' in my setup; as I read the datasheets, this should be okay for my ADC clock of 37.5 MHz (before internal "/ 2" division), i.e. 18.75 MHz after the divider... "
Since there is an issue, why not to test 0b11 ?
Setting BOOST to '0b11' reduces the height of the jumps a bit, but not much (i.e. the "main" jump at ADC code 0x8000 has height ~ 20 instead of ~ 25.
@MasterT wrote:Have RM0433?
" Note: RM0433
adc_sclk is the system clock or system clock divided by two: when the AHB prescaler is set
to 1 (HPRE[3:0] = 0XXX in RCC_CFGR register), adc_sclk is equal to sys_ck, otherwise
adc_sclk corresponds to sys_ck/2. "Frankly, I don't understand what it says, as "/2" and "equals to" stated in the same sentence.
For myself , I'd get RCC-CFGR printed, and changed up and down till I see something.
May be useful: float freq = HAL_RCCEx_GetPeriphCLKFreq(RCC_PERIPHCLK_ADC);
Regarding the clocks: I don't use adc_sclk; I use PLL2P as ADC clock source ("async clock"), which results in adc_ker_ck_input=37.5MHz, and F_adc_ker_ck = 18.75MHz:
Interestingly, HAL_RCCEx_GetPeriphCLKFreq(RCC_PERIPHCLK_ADC)) returns 3750000 (HAL bug?); so it doesn't take into account the fixed "/2" divider in the figure above.
Note that I trigger the ADC via TIM15 every 100µs; and my timing calculation is:
7channels * 16oversampling * (8.5 {tacq} + 7.5 {tconv}) / (37.5MHz / 2) = 95.57µs < 100µs.
When I set the prescaler to PREC[3:0] to "/2", the sampling frequency is halved (i.e. one oversampled sample every 200µs); thus I conclude, that my understanding of f_ADC = F_adc_ker_ck = 18.75MHz is correct.
I also tested halving the ADC clock and compensate by setting oversampling to 8 (instead of 16). With this setting, the jumps remain, but noise is worse.
@MasterT wrote:Regarding code,
reg &= ~0x3Fu; // don't set "rs"-bits reg &= ~(1ul << 29); // disable Deep-power-down reg |= (1ul << 28);I don't know why "u" is appended to HEX value, and why ul instead of UL , could be my C knowledge is rusty.
The "u" (or "U", which does the same) suffix is for "unsigned", and can be ignored here [Programming style: whenever possible, avoid mixing signed and unsigned ints]. "ul" and "UL" suffixes are interchangable in C, and stand for "unsigned long"; which makes sure the operand is at least 32 bits (e.g. on small/old systems where int is only 16 bits).
I bought nucleo-H753zi, and was able to decrypt meaning of linearity factor words.
First, the debugging hardly complicated by fact, that Reading of and Writing to works only Once. To repeat bit tweaking, Calibration has to be completed again.
It may be possible to guess, that reading works once since bits LINCALRDYW (6-1) must be set, and it has to be done by ADC itself.
But I can't imagine why writing works only once, and RM has no comments on this abnormality.
So ADC-3 Single Ended 16-bits configuration was tested. Linearity factors are ADC bit offset correction, where 200 is default and shifting up/down change the specific bits "weight". ADC-3 is different compare to ADC-1/2, somewhere in HAL written that 7 ( 8? )bits only adjustable, and 11-bits for ADC-1/2.
ADC-3 has 8 bits fields , each 10 bits. Means Words 6-4 responsible to offset bits 0-7 MSB, LSB part 8-15 has no adjustment, Words 3-1 dummy.
Linear regression results, name of picture tells bits number and offset.
Bits-7 shows slope, just because asymmetry since only MSB is shifted, and it's completely different to what your pictures show.
My conclusion, that 4 saw-tooth like presented in initial message are not related to calibration, but I 'd re-check on adc-2 later on.
void print_array2(void)
{
Serial.print("\n\tLinear_10b[]:\t");
for( uint16_t i = 0; i < 6; i++) {
uint32_t tempr = linear[i];
for( uint16_t j = 0; j < 3; j++) {
uint32_t tempr2 = ((tempr >> (10 *j)) & 0x000003FF);
Serial.print("\n\t");
print_Hex(tempr2);
}
}
Serial.print("\n\t");
}
void mod_array(uint32_t new_v)
{
uint16_t index1 = indx_lin / 3;
uint16_t index2 = indx_lin % 3; // index1;
uint32_t temp2 = linear[index1];
uint32_t mask = (0x000003FF << (10 * index2));
temp2 &= ~mask;
new_v <<= (10 * index2);
new_v &= mask;
temp2 |= new_v;
linear[index1] = temp2;
}
void write_array(void)
{
if(HAL_ADCEx_LinearCalibration_SetValue(&hadc3, linear) != HAL_OK) {
Error_Handler();
Serial.print("\n\terror SetLinear.");
}
else {
Serial.print("\n\tset to Linear complete.");
}
}Regression linear, quad, cube and error over 512 samples:
N-4, Value = 0x222;
Lin: y = 9.886437 E-1 *x + 6.636996 E-4
Quad: y = -2.929335 E-5 *x^2 + 9.886729 E-1 *x + 6.587521 E-4
Cub: y = -4.796739 E-5 *x^3 + 4.237667 E-5 *x^2 + 9.886440 E-1 *x + 6.612742 E-4
Nmbr --adcR --Diff Diff^2 Diff^3
0 +0.012222 -0.000027 -0.000022 -0.000025
1 +0.014206 +0.000026 +0.000030 +0.000028
2 +0.016113 +0.000002 +0.000007 +0.000004
3 +0.018051 +0.000009 +0.000013 +0.000011
4 +0.019989 +0.000016 +0.000020 +0.000018
5 +0.021912 +0.000008 +0.000012 +0.000010
6 +0.023849 +0.000014 +0.000019 +0.000017
7 +0.025772 +0.000006 +0.000010 +0.000009
8 +0.027740 +0.000044 +0.000048 +0.000046
9 +0.029663 +0.000035 +0.000039 +0.000038
10 +0.031586 +0.000027 +0.000031 +0.000029
11 +0.033539 +0.000049 +0.000053 +0.000051
12 +0.035461 +0.000041 +0.000045 +0.000043
13 +0.037399 +0.000048 +0.000052 +0.000050
14 +0.039307 +0.000024 +0.000028 +0.000026
15 +0.041275 +0.000061 +0.000065 +0.000064
16 +0.043198 +0.000053 +0.000057 +0.000055
17 +0.045120 +0.000045 +0.000049 +0.000047
18 +0.047058 +0.000052 +0.000055 +0.000054
19 +0.049011 +0.000074 +0.000078 +0.000076
20 +0.050934 +0.000066 +0.000069 +0.000068
21 +0.052856 +0.000057 +0.000061 +0.000060
22 +0.054779 +0.000049 +0.000052 +0.000051
23 +0.056717 +0.000056 +0.000059 +0.000058
24 +0.058685 +0.000093 +0.000097 +0.000096
25 +0.060547 +0.000024 +0.000027 +0.000026
26 +0.062485 +0.000031 +0.000034 +0.000033
27 +0.064331 -0.000054 -0.000051 -0.000052
28 +0.066238 -0.000077 -0.000074 -0.000075
29 +0.068146 -0.000101 -0.000098 -0.000099
30 +0.070084 -0.000094 -0.000091 -0.000092
31 +0.072067 -0.000041 -0.000038 -0.000039
32 +0.073975 -0.000065 -0.000062 -0.000063
33 +0.075897 -0.000073 -0.000070 -0.000071
34 +0.077835 -0.000066 -0.000064 -0.000064
35 +0.079788 -0.000044 -0.000041 -0.000042
36 +0.081680 -0.000083 -0.000080 -0.000081
37 +0.083603 -0.000091 -0.000089 -0.000089
38 +0.085480 -0.000146 -0.000143 -0.000143
39 +0.087509 -0.000047 -0.000044 -0.000045
40 +0.089432 -0.000055 -0.000053 -0.000053
41 +0.091339 -0.000079 -0.000076 -0.000077
42 +0.093262 -0.000087 -0.000085 -0.000085
43 +0.095215 -0.000065 -0.000063 -0.000063
44 +0.097168 -0.000043 -0.000041 -0.000041
45 +0.099075 -0.000067 -0.000064 -0.000065
46 +0.101013 -0.000060 -0.000057 -0.000058
47 +0.102936 -0.000068 -0.000066 -0.000066
48 +0.104858 -0.000076 -0.000074 -0.000074
49 +0.106796 -0.000069 -0.000067 -0.000067
50 +0.108734 -0.000062 -0.000060 -0.000061
51 +0.110657 -0.000071 -0.000069 -0.000069
52 +0.112625 -0.000033 -0.000031 -0.000031
53 +0.114532 -0.000057 -0.000055 -0.000055
54 +0.116486 -0.000035 -0.000033 -0.000033
55 +0.118378 -0.000074 -0.000072 -0.000072
56 +0.120316 -0.000067 -0.000065 -0.000065
57 +0.122253 -0.000060 -0.000058 -0.000058
58 +0.124191 -0.000053 -0.000051 -0.000051
59 +0.126236 +0.000061 +0.000063 +0.000063
60 +0.128143 +0.000037 +0.000039 +0.000039
Message cannot exceed 30,000 characters.
451 +0.883224 +0.000119 +0.000121 +0.000122
452 +0.885086 +0.000050 +0.000052 +0.000052
453 +0.887039 +0.000072 +0.000074 +0.000075
454 +0.888962 +0.000064 +0.000066 +0.000066
455 +0.890884 +0.000055 +0.000058 +0.000058
456 +0.892853 +0.000093 +0.000095 +0.000096
457 +0.894745 +0.000054 +0.000056 +0.000057
458 +0.896622 -0.000000 +0.000002 +0.000003
459 +0.898636 +0.000083 +0.000086 +0.000086
460 +0.900543 +0.000059 +0.000062 +0.000062
461 +0.902481 +0.000066 +0.000069 +0.000069
462 +0.904404 +0.000058 +0.000061 +0.000061
463 +0.906342 +0.000065 +0.000068 +0.000068
464 +0.908279 +0.000072 +0.000075 +0.000075
465 +0.910217 +0.000079 +0.000082 +0.000082
466 +0.912155 +0.000086 +0.000089 +0.000089
467 +0.914078 +0.000077 +0.000080 +0.000081
468 +0.916016 +0.000084 +0.000087 +0.000088
469 +0.917953 +0.000091 +0.000094 +0.000095
470 +0.919830 +0.000037 +0.000040 +0.000041
471 +0.921783 +0.000059 +0.000062 +0.000063
472 +0.923691 +0.000036 +0.000039 +0.000040
473 +0.925629 +0.000042 +0.000046 +0.000047
474 +0.927597 +0.000080 +0.000083 +0.000084
475 +0.929474 +0.000026 +0.000029 +0.000030
476 +0.931458 +0.000078 +0.000082 +0.000083
477 +0.933365 +0.000055 +0.000058 +0.000060
478 +0.935333 +0.000092 +0.000096 +0.000097
479 +0.937149 -0.000023 -0.000019 -0.000018
480 +0.939072 -0.000031 -0.000028 -0.000026
481 +0.940994 -0.000039 -0.000036 -0.000034
482 +0.942932 -0.000033 -0.000029 -0.000027
483 +0.944824 -0.000071 -0.000068 -0.000066
484 +0.946732 -0.000095 -0.000091 -0.000090
485 +0.948669 -0.000088 -0.000084 -0.000083
486 +0.950638 -0.000051 -0.000047 -0.000045
487 +0.952499 -0.000120 -0.000116 -0.000114
488 +0.954498 -0.000052 -0.000048 -0.000046
489 +0.956390 -0.000091 -0.000087 -0.000085
490 +0.958313 -0.000099 -0.000095 -0.000093
491 +0.960266 -0.000077 -0.000073 -0.000071
492 +0.962250 -0.000024 -0.000020 -0.000018
493 +0.964142 -0.000063 -0.000059 -0.000057
494 +0.966110 -0.000026 -0.000021 -0.000019
495 +0.968033 -0.000034 -0.000030 -0.000028
496 +0.969925 -0.000073 -0.000068 -0.000066
497 +0.971863 -0.000066 -0.000062 -0.000059
498 +0.973831 -0.000029 -0.000024 -0.000022
499 +0.975708 -0.000083 -0.000078 -0.000076
Updates:
New thread created
with additional details of test setup
