cancel
Showing results for 
Search instead for 
Did you mean: 

ADC with DMA: Watchdog interrupt and DMA values

PSmol.1
Associate II

Hi everyone!

I want to read 2 channels with an ADC via DMA using circular buffer. So far so good. Now I want to use a watchdog for both channels when a certain threshold is reached. However, when the watchdog is triggered and I read the values in the DMA buffer, none of them are above the threshold, meaning they are probably old values.

So the question is: How do I get the ADC value that triggered the watchdog interrupt (values for all channels)?

I am using STM32F746 DISCO with CubeMX, CubeIDE.

Thanks!

Peter

6 REPLIES 6
Aime
ST Employee

Hi @PSmol.1​ ,

Can you check the higher and lower threshold of the analog watchdog ?

0693W00000UnEVQQA3.pngIf you get the analog watchdog interrupt, it means that the value is below the lower threshold or above the higher threshold value.

Please find attached the corresponding Reference Manual.

Best Regards,

A.MVE

PSmol.1
Associate II

Thanks for your response!

The lower threshold is 0, meaning it is a given that the upper threshold was triggered.

Thanks for your response!

The lower threshold is 0, meaning it is a given that the upper threshold was triggered.

Once the analog watchdog triggered :

  • Can you check the value in the register ADC_CR ? It contains the latest value converted.
  • What is the value of the register ADC_DR ? It provides an image of the status bits of the different ADCs

Thanks

A.MVE

> However, when the watchdog is triggered and I read the values in the DMA buffer

How?

If you just look at them from debugger, they are probably long ago overwritten with newer values, as DMA does not stop when debugger stops the processor (i.e. upon breakpoint).

JW

So this is already great information thanks.

I tried multiple ways to read out the values:

1) not read them out at all but use the values to achieve the behaviour that I want (i.e. comparing the two values to decide what the triggering channel was).

2) debugging (as you mentioned, not a good idea).

3) output over usart.