STM32CubeIdeMx doesn't allow DMA for ADC in continuous scan mode

[Brice_38FR]

Hi

I'm trying to configure my project with STM32CubeIde 1.2.1

I want to use ADC1 to perform temperature and vrefint measurement.

So I configure my adc & dma :

But I'm not enable in cube to enable the DMA option, only disable is possible.

If I enable the flag manually in the code generated, I don't have any problem and the code is running as expected (continuous acquisition of both channel with an interrupt each time the acquisition is complete)

Is there a reason this option isn't possible in cube ?

[Brice_38FR]

More infos, I don't have this problem on a clean/empty project

[Khouloud ZEMMELI]

​Hello @Community member​ 

Could you please give me more details (scenario) and share your project (where did you find issue)?

Thanks,

Khouloud

[Brice_38FR]

Attached is the project *.ioc

[Khouloud ZEMMELI · Accepted solution]

​Issue will be fixed in the next release.

Best Regards,

Khouloud

[Brice_38FR]

Ok cool !

[n2wx]

This is a deal breaker. it's an obvious use case I beat my head against for three days before resorting to an ugly hack deiniting and reiniting the HAL driver on a schedule and iterating through the channels.

If the fix doesn't include a working example for the H7 *including* an Atollic linker script that correctly identifies the h7 DMA-capable areas it is not fixed. I bet it's not fixed.

Please maintain an errata for the product.

When's the next release? Should I be frightened of regressions? Because I am terrified

[Brice_38FR]

I'm not sure to understand why it's a deal breaker.

Ok it's not cool to have to manually change the generated code.

But once you know that you have to be vigilant after you generate your program (quite easy with git to discard the change), the continuous scan mode with DMA is working fine.

[n2wx]

The lack of errata and no schedule and broken or missing examples combine to a deal breaker. I hope that helps.

EDIT: I realize I'm putting too much confidence in ST's ability to deliver working libraries.

[Piranha]

They've introduced STM32 family in 2007 and haven't been able to make a single piece of quality code for any of them. The HAL library was introduced in 2014 and is the most flawed. Even 6 years later it is still not working and there are no signs of ST being cared of it. Meanwhile hardware guys have introduced Cortex-M7 based MCUs and even radically different STM32H7 series, for which the HAL team fails to even understand the working principles. So, let's be real - the HAL team is incapable of doing their job and the higher management is too blind to see that.