STM32L ADC Converter - Debugger reset ADC_ISR_EOC

[davide_mp]

Hi everyone !

I have a curiosity and I ask you all how to interpret ...
The behavior of the ADC_ISR_EOC bit during debugging is unclear, it is reset and I don't understand why.

Code :
// TimerSecurity is a security timer that runs every 1 msec
1) TimerSecurity = 10;
2) ADC1->CR |= ADC_CR_ADSTART;
3) while ((ADC1->ISR & ADC_ISR_EOC) == 0) {
4) if(TimerSecurity == 0)
5) breaks;
6) }
7)
8) ADC1->CR |= ADC_CR_ADDIS;
9) return ADC1->DR;

While debugging...

- Case 1
I put a breakpoint on lines 1 and 9
the debugger stops at line 2
I start the F5 debugger
the debugger stops at line 9
the ADC_ISR_EOC bit seen in a watch window is LL1
the TimerSecurity is still 10

- Case 2
I put a breakpoint on lines 1 and 9
the debugger stops at line 2
I step over the F10 debugger
the ADC_ISR_EOC bit seen in a watch window is LL1
I start the F5 debugger
the debugger stops at line 9
the ADC_ISR_EOC bit seen in a watch window is LL0
the TimerSecurity is 0

I hope I have been clear, I would like to understand who resets the bit
ADC_ISR_EOC.
Has this happened to any of you?

[waclawek.jan]

Debugger is intrusive.

In this particular case, the debugger is probably displaying also ADC_DR, and reading ADC_DR (regardless of whether by processor or debugger) clears ADC_ISR.EOC.

 

JW

[davide_mp]

HI,

you are great...
This is just something I would never have thought of. It would explain the anomaly!

So I'll ask you something else:
Sometimes, I still haven't understood why, the AD conversion of the CH17 VREFINT gives me 0x00000000 instead of a valid value.
Has it ever happened to you ?
I read in the RM0451 incorrect sheet that perhaps there is a problem when you perform two single conversions consecutively, if you don't perform them within a certain time then the result could be wrong.
I'm trying to replicate the problem to check if the proposed solution is valid.

Come on, it's happened to you before...

[waclawek.jan]

> Sometimes, I still haven't understood why, the AD conversion of the CH17 VREFINT gives me 0x00000000 instead of a valid value.
> Has it ever happened to you ?

No.

JW