ADC reads are out of order at certain frequencies

[TheZoq2]

At some ADC clock values, the ADC reads values out of order, or to the wrong channels.

let clocks = rcc.cfgr.freeze(&mut flash.acr);
hprintln!("adc freq: {}", clocks.adcclk().0).unwrap();

let mut adc1 = adc::Adc::adc1(p.ADC1, &mut rcc.apb2, clocks);

let mut gpioa = p.GPIOA.split(&mut rcc.apb2);

let mut ch0 = gpioa.pa0.into_analog(&mut gpioa.crl);
let mut ch1 = gpioa.pa1.into_analog(&mut gpioa.crl);
let mut ch2 = gpioa.pa2.into_analog(&mut gpioa.crl);

loop {
    let r1: u16 = adc1.read(&mut ch0).unwrap();
    let r2: u16 = adc1.read(&mut ch1).unwrap();
    let r3: u16 = adc1.read(&mut ch2).unwrap();

    hprintln!("{}, {}, {}", r1, r2, r3);
}

Using the above modified examples/adc.rs, with 3.3V connected to to PA0, 0V
connected to PA1, and 2V connected to PA2, the readings returned are

2514, 4095, 0
2516, 4095, 0
2519, 4092, 0
2514, 4094, 0
2528, 4094, 0
2531, 4095, 1
2512, 4093, 0
2506, 4095, 0

not 4096, 0, 2510 as expected.

This can be fixed by setting the adcclk to 2 MHz in the clock initialisation.

I'm going to work on a patch to fix this, but i'm reporting it now so noone
else has to debug the issue :)

[TheZoq2]

Update, it looks like this behavior happens when the ADC prescaler is 6 or 8. For 2 and 4, it behaves normally

Edit:

Some more observations:

• Sample time seems to affect things as well, T_1, T_7, and T_239 works, the others do not.
• In addition to being ordered incorrectly, the readings are also of lower quality when the bug occurs. Especially the first reading which is completely incorrect

[TheZoq2]

And another update:

git bisect indicates that the functionality broke in #88

6180620

[TheZoq2]

After reverting the changes to rcc and adc and watching the problem persist, I am now suspecting that a bug introduced in the PAC crate between 0.7.0 and 0.8.0 is causing the issues