Causes for ADC calibration not finishing?

[SKled.1]

I am porting a working project from an STM32F0 to an L0.

For that I let CubeIDE generate init code for the new MCU and replaced stuff that changed in my code. (next to adapting my modified linker script and all that)

The code gets stuck on waiting for the calibration to finish.

while (adc->CR & ADC_CR_ADCAL) {}

At first it looked like the ADC had no clock, judging from the clock tree depiction in CubeIDE, so I changed the ADC clock to async and it's getting the internal 16MHz RC oscillator signal now.

That didn't help, though.

Some register bits I think might be relevant, when breaking into that loop with the debugger:

• ISR: is completely 0, i.e. also ADRDY and EOCAL
• CR: ADEN=0, ADDIS=1, ADSTART=0, ADSTP=0, ADVREGEN=1, ADCAL=1
• CFGR1: DMAEN=1, all else 0
  • old note. I found that already, it should be 0. Setting it to 0 before calibration still does not make it complete
• CFGR2; OVSE=1, OVSR=3, rest 0
• CCR: LFMEN=0 - and async clock is 16MHz, VREFEN=1, rest 0

So as in the project for the F0, the ADC is not enabled during calibration, as is demanded in the reference manual.

Anything else wrong?

I wonder why ADDIS is still 1, if I read the reference correctly, the disabling of the ADC is ongoing when this is 1?

Edit: Funny. Before calibration, the code sets CR ADDIS to disable the thing - just for good measure, as it needs to be disabled. This worked in the old project. But here now, apparently, when the ADC is not enabled and this is done, this prevents the calibration from completing.

I wonder why that is. The calibration procedure in the reference does not mention something like that. The description of the ADDIS bit says "only effective if ADEN=1", ok, but "only effective" does not sound like "trashes other operations" to me ;)

[waclawek.jan]

It does not "thrash" other operations; it just works as described. Okay, the description might've been cleaner, but the message is "don't set ADDIS if ADEN is not set" and that's quite clear.

The ADC in every STM32 is a complex and quirky beast, changes quite significantly from family to family, and it pays off to follow the instructions closely.

JW

[SKled.1]

How does it work as described? There is nothing in that text suggesting that the thing will neither work for calibration nor otherwise when you do that. I basically discovered an undocumented "feature".

"Don't set that if..." is not clearly the message either, unless I overlooked some other part of text. It says that stopping the ADC is not effective when ADEN=0. That can mean a lot of things. For instance, that nothing at all happens, bad or otherwise. In this case, it is a bit difficult to closely follow the instructions. It could be an advantage (slightly smaller code) to just always do that one thing in a routine, and if the manual text sounds like that's permissible, why not use that for an optimization. I don't see a clear default route to go, from that exact wording.

Not without going into it preloaded with a certain bias, like your experience with these series of MCUs might provide.

IMHO, a good manual should not require that, though.

[waclawek.jan]

@Community member​ ,

You've said you are coming from 'F0. Just for the laughs, have a look at the parallel thread https://community.st.com/s/question/0D53W00000gh8CySAI/rm0091-adc-chapter-not-very-clear where we are bashing the 'F0 RM ADC chapters... :)

Yes, documentation can always be improved.

@Imen DAHMEN​ , can you please have a look if this particular item could be improved, i.e. if the note to ADDIS in the 'L0 RMs can say more imperatively that ADEN *must* be set if ADDIS is to be set. Thanks.

JW

[SKled.1]

Hehe, thanks. I have not used exactly a huge number of different devices. But there have been manuals were it was almost mysteriously hard to figure out what you really need to do. So overall in my limited experience, it seems STM32 manuals are generally well put together.

Just sometimes, in some corner, some weird thing is hiding.

[Imen.D]

Hi @Community member​ , @Community member​ ,

I raised your feedback internally to take into consideration.

Thanks @Community member​ for pointing out to me this post.

Imen

[waclawek.jan]

Thanks, Imen.

Jan

@Imen DAHMEN​