2025-11-26 5:07 PM
Hi all,
I am trying to understand the relationship between CCRDY and CHSELR. Unfortunately, there is a bit of bad grammar in the Reference Manual on this subject, which is not helping...
The manual seems to say (and some examples support this) the sequence is -
ADC1->ISR |= ADC_ISR_CCRDY
ADC1->CHSELR = adc_channel;
while((ADC1->ISR & ADC_ISR_CCRDY) != ADC_ISR_CCRDY) {};
ADC1->CR |= ADC_CR_ADSTART; // Start the converstionThis sequence doesn't make sense. What would happen if there was an interrupt between clearing the CCRDY and writing the CHSELR?
Can anyone explain the internal workings of the ADC on this topic?
Kind regards
Pedro
2025-11-26 5:52 PM
Include your full chip part number. Crystal ball isn't working.
2025-11-26 6:12 PM
Thanks for your reply.
That's a good question. I believe that there is only a few with the CCRDY. STM32G050 is one. I am assuming that all devices with the CCRDY will operate the same?
Kind regards
Pedro
2025-11-26 8:21 PM - edited 2025-11-26 8:25 PM
> What would happen if there was an interrupt between clearing the CCRDY and writing the CHSELR?
Code seems okay to me, except to clear CCRDY, write 1 to only that bit. Don't read-modify-write as that may clear other flags as well.
CCRDY only gets set when new channel settings are applied. Won't get a CCRDY interrupt before that, if that was the concern.
(I edited this reply, original was incorrect.)
> I am assuming that all devices with the CCRDY will operate the same?
Probably, but it's easier and more useful to talk about something specific than to find all chips that have CCRDY and cross-reference the manuals to see if the ADC behaves the same. Lots of different ADC peripherals among STM32 chips.
2025-12-04 2:57 PM
Thanks for that edit :)
BTW, there is a bug in the LL version of MX_ADC_Init() - it exits with the CHRDY flag reset!
A work around is
MX_ADC_Init();
ADC->CHSELR = ADC->CHSELR; //fingers crossed that your optimiser dosn't remove this
... now wait for the CHRDY flag to go highKind regards
Pedro