Strange behavior of STM32L053 ADC

[Zoran Daric]

Posted on February 01, 2017 at 18:02

Hi

By writing a program for very simple one channel ADC I faced with very strange behawior of the ADC in my MCU. During tests of the A/D converter, I read Vrefint (channel 17). If very shortly after calibration, about 1 second, I do the A/D conversion, everything is OK, I have correct value. In case I wait for a few seconds (more then 4 seconds) result is wrong. If I do second read very shortly, less then 4 second, I got correct result. If I do reading every second, the results are OK except first one. Note that incorrect value always is 2048 decimal (very strange).

In case I do reading two different channels effect is the same. This mean that I always have to do two conversions to have correct value or to do readings non-stop for all the necessary channels even if I don't need it.

In the attachment are flowcharts for ADC calibration, setup and conversion. I need to know what I'm doing wrong.

Note that clock source for the ADC is HSI at 4MHz. All other parameters except parameters changed in setup after calibration are default values after reset. Changing sampling time doesn't help.

    Regards,

    Zoran

[waclawek.jan]

Posted on February 01, 2017 at 18:33

Please post a minimal but complete compilable code exhibiting the problem.

JW

[Zoran Daric]

Posted on February 01, 2017 at 23:16

Hi,

Here is a program that shows the problem I have. Program do:

- HSI oscillator init. (4MHz output)

- ADC clock enable

- ADC calibration

- Two A/D conversions of Vref (channel 17)

Between conversions there is a pause of around 6 second. Result of

the first conversion is in R5 and result of the second conversion in R6.

Second result is always 0x800 (2048 decimal). If pause is shorter these

two results are the same around 0x5da (1498 decimal) in my case. Maybe I

do something wrong or maybe there is a hardware problem on my STM evo

board I got from Arrow.

Regards

Zoran

W dniu 2017-02-01 o 18:33, waclawek.jan pisze:

>

STMicroelectronics Community

<https://community.st.com/?et=watches.email.thread>

>

Re: Strange behavior of STM32L053 ADC

reply from waclawek.jan

<https://community.st.com/people/Waclawek.Jan?et=watches.email.thread>

in /STM32 MCUs Forum/ - View the full discussion

<https://community.st.com/message/145218-re-strange-behavior-of-stm32l053-adc?commentID=145218&et=watches.email.thread#comment-145218>

>

________________ Attachments : ADC_Problem.rar : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hyxc&d=%2Fa%2F0X0000000bER%2FLxBB60syE1VmUiTjFz4CJke2R8nTD7N6X1mqIY_heKI&asPdf=false

[Zoran Daric]

Posted on February 08, 2017 at 09:24

 ,

 ,

Hi,

Did you try my code?

Zoran

W dniu 2017-02-01 o 18:33, waclawek.jan pisze:

>,

STMicroelectronics Community

<,https://community.st.com/?et=watches.email.thread>,

>,

Re: Strange behavior of STM32L053 ADC

reply from waclawek.jan

<,

in /STM32 MCUs Forum/ - View the full discussion

<,https://community.st.com/0D70X000006STu5SAG

>,

[waclawek.jan]

Posted on February 12, 2017 at 23:50

I had to convert your code to GNU asm...

Confirming your finding, using a L053 DISCO.

It did not end up with the faulty conversion result (0x800) all the time even with the long pause, but most of the time it did (once is disturbing enough of course).

I tried to get rid of the problem by switching on AUTOFF, no avail. Changing sampling time did not help either, exactly as you reported :)

Time to pester ST directly.

JW

[Zoran Daric]

Posted on February 13, 2017 at 00:25

 ,

 ,

Hi,

As I understand, you managed to reproduce problem on the same

evo-board model but using different assembler. I think that problem

exists, and that different time is due to different silicon. Probably I

have dice from extremely 'not good' silicon. This is very important for

me, because very soon begin production of a prototype and then the mass

production of device.

Zoran

W dniu 2017-02-12 o 23:51, waclawek.jan pisze:

>,

STMicroelectronics Community

<,https://community.st.com/?et=watches.email.thread>,

>,

Re: Strange behavior of STM32L053 ADC

reply from waclawek.jan

<,

in /STM32 MCUs Forum/ - View the full discussion

<,https://community.st.com/0D70X000006SPVBSA4

>,

[Dvorak.Peter]

Posted on February 13, 2017 at 03:01

As a wild guess, I would recheck the ADC clock frequency.

[Zoran Daric]

Posted on February 13, 2017 at 05:07

Hi Peter,

Thank you for advice but generally I don't think that checking ADC

clock can solve the problem, because everything is build inside the chip

and we don't have any influence on it. Only what we can do is to access

via registers. Please tell me, did you have the same problem with ADC,

and did you managed to solve the problem?

Zoran

W dniu 2017-02-13 o 03:03, dvorak.peter pisze:

>

STMicroelectronics Community

<https://community.st.com/?et=watches.email.thread>

>

Re: Strange behavior of STM32L053 ADC

reply from dvorak.peter

<

in /STM32 MCUs Forum/ - View the full discussion

<https://community.st.com/0D70X000006SyFuSAK

>

[danilo239955]

Posted on February 13, 2017 at 08:43

Hi,

I don't have experience with the STM32L0 family but in my opinion to start the conversion the code:

movs r1,#0x04

str r1,[r0,#Adc_Cr]

can be dangerous because the bit ADVREGEN of the Control Register is cleared.

The 'canonical' approach should be (example):

movs r3,#0x04

ldr r1,[r0,#Adc_Cr] orrs r1,r3 str r1,[r0,#Adc_Cr] BRDanilo

[waclawek.jan]

Posted on February 13, 2017 at 09:04

Fair point, although, according to RM, ADVREGEN can't be switched off while ADEN is on (and it is on all the time, checked).

I can check it on real hw only in the evening.