Bug in the generated code from STM32CubeMX V 6.3.0 using ADC and DMA: Needs manual change

[KayG]

I am using the following settings:

STM32 CubeMX version 6.3.0

Microcontroller: STM32L4P5ZGTxP

Enabled peripherals:

ADC1:

• SCAN mode: disabled
• CONT and DISCONT mode disabled
• Continuous DMA requests enabled
• Using EXTI 11 to run

DMA1 channel 1:

• Circular mode
• Memory word increments
• No DMA synchronization requests

When I generated the code (checked for both Keil and Cube IDE), the initialization part of the main looked like this:

...
MX_GPIO_Init();
MX_ADC1_Init();
MX_DMA_Init();
 ...

The ADC runs, and if the interrupts are set, you'll get the interrupts. But the DMA callback routine is never entered.

When I changed the order to first initialize the DMA, and then the ADC1, the problem was solved.

I would like to see if anyone can confirm this, or is it due to something else (possibly?).

[thundertronics.com · Accepted solution]

It is well known already. There are several topics on this forum. One of the reasons BDMA not worked with ADC3 on H7, etc. Current solution is to change default initialization order in Device configuration tool (pinout/peripheral editor):

1. Open "Project Manager" (tab near Pinout / Clock Configuration)
2. Project Manager → Advanced Settings → Generated Function Calls
3. Use tiny arrow buttons near this list to move MX_DMA_Init() above MX_ADC1_Init()
4. Save the project

This way newly generated code will have right order even after making changes in IOC file and re-generating the code.

Btw, there are also some other features on those tabs worth noting.

[АЮшко.1]

I had a similar problem with UART solved the problem as follows. In the vastness of the Internet, I found an article where similar rakes were described and how to fix it, the DMA of the periphery with which you will work should be configured first of the periphery itself. As it turned out, the initialization order can be configured in the Cube in the Project Manager\Advanced Settings tab, set as the author and, lo and behold, the data began to be accepted. The in-tweets also don't say anything about this joke.

[KayG]

Thanks for the info

[Amel NASRI]

Hi @KayG​ ,

As confirmed by @thundertronics.com​ , this is a known regression issue faced with STM32CubeMX 6.3.0.

Good news: new STM32CubeMX version 6.4.0 is already available on ST web site and it should fix this issue.

Could you please check this on your side and confirm if the problem is well resolved?

-Amel