RM0091 - ADC chapter not very clear

[Kraal]

Hi,

The RM0091 rev 9 has some contradictions and typos in the ADC chapter.

1. on page 234, 13.4.4 says that the registers IER, CFGRi, SMPR, TR, CHSELR and CCR must be configured only after ADEN has been set (and presumably that ADRDY is also set).
2. However in section 13.5.2, it is said that the RES bits in CFGR1 must only be changed when ADEN = 0.
3. So which one of the above should I follow ?
4. on page 252, for calculating the Vdda value, a value of .3V is mentionned twice (I presume 3.3V, as written in the next formula).

Best regards.

[waclawek.jan]

https://community.st.com/s/question/0D50X00009XkaB8SAJ/rm0367-stm32l0x3-discrepancies #7

I wouldn't be surprised if any of the other issues mentioned there would be pertinent to the 'F0 ADC, or for that matter, for ADC of the same version.

https://community.st.com/s/ideazone#0873W000000KykTQAS

JW

[Imen.D]

Hello @Kraal​ , @Community member​ ,

Thanks for pointing out these typos.

I am checking this and I will raise your feedback internally for clarification and correction in the impacted reference manuals.

Thanks

Imen

[waclawek.jan]

Thanks, Imen.

Jan

[Kraal]

Thanks @Imen DAHMEN​ and @Community member​ .

Wow, @Community member​ , the thread you mentioned goes back to 2017, and yet the F0 RM has not been corrected. Did ST change the L0 RM after your remarks ?

I must say that on all my projects involving an F0 uC, I always configured the ADC before enabling it, and I never had any issues.

But now I really need to know if my devices in the field might fail because of that, or not...

So please @Imen DAHMEN​ I need a clear answer as fast as you can.

Best regards,

Kraal

[waclawek.jan]

The formulation of said "warning" in RM0367 has been changed to:

For all the other control bits in the ADC_IER, ADC_CFGRi, ADC_SMPR, ADC_TR,

ADC_CHSELR and ADC_CCR registers, refer to the description of the corresponding

control bit in Section 14.12: ADC registers.

and indeed, most if not all control bits/bitfields in the related registers now have a note, saying when the given bit/bitfield must not be changed; most of them say

Note: The software is allowed to write this bit only when ADSTART=0 (which ensures that no conversion is ongoing).

Except of the "logical" ones (ADSTART, ADDIS), I believe that only ADC_CALFACT.CALFACT requires ADEN=1.

The 'F0 ADC may/is different. e.g. https://community.st.com/s/question/0D53W00000gh4S1SAI/causes-for-adc-calibration-not-finishing

RM00901 for the 'F0 hasn't been updated from v9 for ages (RM0360 probably too). I believe there are tons of changes pending.

JW

[Imen.D]

Hi @Kraal​ ,

We agree that statement is unclear, but it is explicit in Resolution section as well as in bitfield description:

So, the proposition is to add a line in 13.4.4 to exclude RES from this register list to configure once ADEN=1.

Note that the last change for RM0091 was since 2017. Therefore, I will request to update this RM and take into consideration your reported typos.

For this post (since 2017) RM0367 (STM32L0x3) discrepancies related to the STM32L0 series: the reported errors (before December 207) are taken into account in the RM0367 Rev 6 (published in December 2017).

So, I will request also to review and update this RM, to correct the typos that have not yet been corrected.

Thanks for your contribution. All your feedback are welcome in order to improve our documents.

Imen

[Kraal]

@Community member​ correct, after reading again the registers section of the ADC chapter, it is almost always said that the modification of bit nn must be done when ADSTART = 0 (so no ongoing conversion). Obviously ADSTART = 1 is only possible when the ADC has been enabled before.

So with the exception of the RES bits, I believe that ADEN must be set before configuring the ADC.

As said before, I never had any issue doing otherwise, but you never know what could go wrong with the details.

@Imen DAHMEN​ I would suggest an additional snippet at the end of the RM with a configuration of the ADC so that it should be impossible to misunderstood.

Best regards,

Carl