ADC - DMA - Memory takes too long to complete

[jlthompson]

I started a new STM32G0B1 project based on the example project, ADC_MultiChannelSingleConversion, and added FreeRTOS. The default task makes the same HAL_ADCEx_Calibration_Start and HAL_ADC_Start_DMA ffunctino calls as the example, starts a periodic timer to fire every 10 ms and then goes into an infinite loop where all it does it repeatedly call  osDelay(1000).

Every time the timer I started fires, it calls a function that increments a counter, toggles the green, LED,makes the same HAL_ADC_Start call the example does, delays, calls HAL_Delay(1), and then checks ubDmaTransferStatus, also the same way the example does I also print out the loop counter and the computed values from the example, plus a few more for seven altogether, and then clear ubDmaTransferStatus.But if ubDmaTransferStatus is not set, I print out a line of dashes.

I eliminated the blue button entirely from the project because I'm using the timer for the same purpose..

Here's the issue. the flag, ubDmaTransferStatus, is only set every seventh time the timer fires. I've lengthened the timer period to 100 ms, increased the HAL_Delay(1) parameter in the timer calback function to 100, and chosen the shortest sampling time. Still, I only see ubDmaTransferStatus get set every seventh time the timer fires.

All the ADC and DMA code is copied and pasted from the example project.

I'm sure I'm missing something or doing some fundamental thing incorrectly to get this result, but what?

The Core files are attached/

 

[TDK]

HAL_ADC_Start isn't called anywhere within the files you attached. Not in main(), not in the default task, not in any of the interrupt handlers in *_it.c.

Likewise, I don't see ubDmaTransferStatus appearing anywhere in a text file search of the files.

 

Sure you attached the relevant files? Am I missing it?

[jlthompson]

My apologies, I zipped up the wrong project. Please see the new attachment.

[jlthompson]

Out of desperation, I changed the conversion mode from scan to continuous — that seems to have solved the issue. I suppose that means that conversions are happening as fast as possible, and I'm just grabbing one from each input whenever my timer fires. It appears that way because consecutive readings are slightly different.

Does that sound right to you?