In addition to "normal" ADC inputs from pins, in most STM32 there are also internal ADC inputs, e.g. internal voltage reference (VREFINT), internal temperature sensor (TEMP) and VBAT (backup-battery supply pin) measurement (and in newer STM32, also outputs from some DAC channels). These need to be switched on/off because of power consumption associated with these sources (which is especially important for the VBAT measurement, which could drain the backup battery if left on permanently.

In 'F4 and 'F7 families, for unknown reasons, TEMP and VREFINT measurements are switched on/off simultaneously, using one control bit ADC_CCR.TSVREFE. Also, both VBAT and TEMP are fed to the same ADC input through a switch, controlled by the control bit which also switches on the VBAT measurement, ADC_CCR.VBATE.

These two constraints together mean, that between measuring VBAT and TEMP, and - more surprisingly - between measuring VBAT and VREFINT, a software intervention is needed, to set the proper combination of those two control bits. As a consequence, putting both VBAT and TEMP, or both VBAT and VREFINT, into one automatic sequence of measurements (e.g. using Continuous conversion mode together with DMA) is not feasible.

In Cube/HAL, ADC sequences are set up by repeatedly calling HAL_ADC_ConfigChannel() to set individual elements ("ranks") of the sequence, before starting the sequence itself. This function also switches on/off the above two control bits, if channel being set up is one of VREFINT/TEMP/VBAT. If a subsequent call to the same function sets up another "rank" for a different VREFINT/TEMP/VBAT channel, that call sets those control bits to a possibly different state. Depending on the particular sequence of calls, users then find some of the results being of unexpected value, due to the control bits not being switched in between the conversions (as experienced e.g. by user colorhacker).