Skip to main content
TNish.2
TNish.2
Associate
October 30, 2021
Question

ADC sampling rate is different from the set value

  • October 30, 2021
  • 6 replies
  • 2600 views

I want to run the ADC using DMA and Dual mode.

The sampling rate was set to 80kS / s using TIM3. The board I am using is Nucleo 64 STM32 F446.

In order to confirm whether the ADC is really running at 80kS / s, I described "HAL_GPIO_TogglePin" in "DMA2_Stream0_IRQHandler (void)" and confirmed it by observing the pulse width with an oscilloscope.

As a result, it was found that the ADC is running at about 660us (1.5kHz in frequency). (According to the data sheet, the STM used can have a maximum sampling rate of 2.4 MS / s.)

Why doesn't my program get the sampling rate I set?

My program only runs the ADC and does nothing else.

Our development environment

win10

STM32CubeIDE Ver1.6.1

Board used: Nucleo64 STM32F446

Thank you for your reply.0693W00000GVzYFQA1.png0693W00000GVzY5QAL.png0693W00000GVzY0QAL.png0693W00000GVzXlQAL.png0693W00000GVzXWQA1.png0693W00000GVzXMQA1.png0693W00000GVzXHQA1.png

This topic has been closed for replies.

6 replies

TDK
TDK
October 30, 2021

How is printf implemented? It could be blocking execution.

"If you feel a post has answered your question, please click ""Accept as Solution""."
TNish.2
TNish.2Author
Associate
October 31, 2021

Thank you for your answer

printf is implemented as follows.

Also, the buffer setting was missing, so I added it.

Also, when the printf described in stm32f4xx_it.c was deleted, the pulse width became 122us (8.2kHz).

Sorry to trouble you, but thank you for your reply.0693W00000GW0FsQAL.png0693W00000GW0FYQA1.png

TDK
TDK
October 31, 2021

A blocking call in the IRQ handler will certainly cause issues.

Your post mentions you were expecting 80kS/s, but your timer settings indicate 8kS/s.

90 MHz / 11252 = 8kHz, so all is as expected right?

"If you feel a post has answered your question, please click ""Accept as Solution""."
TNish.2
TNish.2Author
Associate
October 31, 2021

I'm sorry.

Fixed 11252 to 1125.

As a result, the DAM interrupt was generated only once, and then no interrupt was generated. (printf has been deleted.)

This phenomenon was confirmed by setting a breakpoint in HAL_GPIO_TogglePin (GPIOA, GPIO_PIN_5) of the first image "stm32f4xx_it.c". Immediately after the program starts, break only once with HAL_GPIO_TogglePin (GPIOA, GPIO_PIN_5). After that, if you press the resume button, it will not break.

Thank you for your reply.

TDK
TDK
October 31, 2021
Why would it work fine with 11252 but then not work with 1125?
Setting breakpoints and pausing the program is rather disruptive as timers continue to tick away in the background. Likely you're hitting an overflow type error as a result.
"If you feel a post has answered your question, please click ""Accept as Solution""."
TNish.2
TNish.2Author
Associate
October 31, 2021

Thank you for taking the time.

When I run the program without setting a breakpoint, the pin output toggles only once and there is no change thereafter.

I don't know why it works on 1125 but not on 11252.

I have set the sampling time to 56 cycles, is this too large?

Terms & ConditionsAccessibility statement