Possible bug in LL STM32 drivers (reading injected ADC)

[SFort.1]

I have STM32F4, using ADC3 for injected conversions. Driver code is generated using the latest CubeMX. I have 4 channels in group and was using LL_ADC_INJ_ReadConversionData12(ADC3, ADC_INJECTED_RANK_1) for reading (where rank was from 1 to 4). But the values that I got back were all exactly the same and consistent with expected value on the first channel. Accessing ADC3->JDR1 to JDR4 gives correct results. If I understand LL_ADC_INJ_ReadConversionData12 correctly, then this is a bug.

volatile uint32_t jsqr = ADC3->JSQR;
  volatile uint32_t j1 = ADC3->JDR1;
  volatile uint32_t j2 = ADC3->JDR2;
  volatile uint32_t j3 = ADC3->JDR3;
  volatile uint32_t j4 = ADC3->JDR4;
  volatile uint16_t h1 = LL_ADC_INJ_ReadConversionData12(ADC3, ADC_INJECTED_RANK_1);
  volatile uint16_t h2 = LL_ADC_INJ_ReadConversionData12(ADC3, ADC_INJECTED_RANK_2);
  volatile uint16_t h3 = LL_ADC_INJ_ReadConversionData12(ADC3, ADC_INJECTED_RANK_3);
  volatile uint16_t h4 = LL_ADC_INJ_ReadConversionData12(ADC3, ADC_INJECTED_RANK_4);
  volatile uint16_t regular = LL_ADC_REG_ReadConversionData12(ADC3);

[Imen.D]

Hello @SFort.1 

Please share your ioc file to help our team reproduce the issue.

[SFort.1]

Here's my ioc file, it's not exactly the same as when I submitted the issue, but the ADCx configuration is unchanged.

The function in LL looks like this:

__STATIC_INLINE uint16_t LL_ADC_INJ_ReadConversionData12(const ADC_TypeDef *ADCx, uint32_t Rank)
{
  __IO uint32_t const *preg = __ADC_PTR_REG_OFFSET(ADCx->JDR1, __ADC_MASK_SHIFT(Rank, ADC_INJ_JDRX_REGOFFSET_MASK));

  return (uint16_t)(READ_BIT(*preg,
                             ADC_JDR1_JDATA)
                   );
}