STM32G4 DMA DAC not working because of CubeMx code generation

[giuliomoro]

Caution The Issues are strictly limited for the reporting of problem encountered with the software provided in this project. For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum.

Describe the set-up

• The board (either ST RPN reference or your custom board). STM32G491KEU6 on a custom board.

• IDE or at least the compiler and its version. STM32Cube v1.7.0

Describe the bug CubeMx sometimes generates the function calls to MX_DAC1_Init(), MX_DMA_Init() in an order such that the DMA doesn't work. I experimentally found that MX_DAC1_Init() followed by MX_DMA_Init() doesn't work, whereas when they are called the other way around, it works.

How To Reproduce

1. Indicate the global behavior of your application project.

I use CubeMx to set DAC1_CH1 triggered by TIM6 and serviced by DMA1 channel 1.

2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...).

The CubeMx code generator.

3. The use case that generates the problem.

Servicing the DAC via DMA.

4. How we can reproduce the problem.

This archive STM32G4Cube-bug-report.zip contains two .ioc files and the two main.c files they generate. Both .ioc files set DAC1_CH1 triggered by TIM6 and serviced by DMA1 channel 1. However, they generate different code. The salient difference between the two .ioc files is the order at these lines:

< ProjectManager.functionlistsort=1-SystemClock_Config-RCC-false-HAL-false,2-MX_GPIO_Init-GPIO-false-HAL-true,3-MX_DAC1_Init-DAC1-false-HAL-true,4-MX_DMA_Init-DMA-false-HAL-true,5-MX_TIM6_Init-TIM6-false-HAL-true
---
> ProjectManager.functionlistsort=1-SystemClock_Config-RCC-false-HAL-false,2-MX_GPIO_Init-GPIO-false-HAL-true,3-MX_TIM2_Init-TIM2-false-HAL-true,4-MX_DMA_Init-DMA-false-HAL-true,5-MX_DAC1_Init-DAC1-false-HAL-true,6-MX_TIM6_Init-TIM6-false-HAL-true

As a result, they generate the following main() functions (from the respective main.c files:

main-Working.c:

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_DAC1_Init();
  MX_TIM6_Init();
  /* USER CODE BEGIN 2 */

main-NotWorking.c:

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_DAC1_Init();
  MX_TIM6_Init();
  /* USER CODE BEGIN 2 */

(note the how MX_DMA_Init() and MX_DAC1_Init() are swapped in the two cases). Now, with the minimal example code that follows (borrowed from here):

#define NS  128
    static uint32_t Wave_LUT[NS] = {
    2048, 2149, 2250, 2350, 2450, 2549, 2646, 2742, 2837, 2929, 3020, 3108, 3193, 3275, 3355,
    3431, 3504, 3574, 3639, 3701, 3759, 3812, 3861, 3906, 3946, 3982, 4013, 4039, 4060, 4076,
    4087, 4094, 4095, 4091, 4082, 4069, 4050, 4026, 3998, 3965, 3927, 3884, 3837, 3786, 3730,
    3671, 3607, 3539, 3468, 3394, 3316, 3235, 3151, 3064, 2975, 2883, 2790, 2695, 2598, 2500,
    2400, 2300, 2199, 2098, 1997, 1896, 1795, 1695, 1595, 1497, 1400, 1305, 1212, 1120, 1031,
    944, 860, 779, 701, 627, 556, 488, 424, 365, 309, 258, 211, 168, 130, 97,
    69, 45, 26, 13, 4, 0, 1, 8, 19, 35, 56, 82, 113, 149, 189,
    234, 283, 336, 394, 456, 521, 591, 664, 740, 820, 902, 987, 1075, 1166, 1258,
    1353, 1449, 1546, 1645, 1745, 1845, 1946, 2047
};
  HAL_DAC_Start_DMA(&hdac1, DAC_CHANNEL_1, (uint32_t*)Wave_LUT, NS, DAC_ALIGN_12B_R);
  HAL_TIM_Base_Start_IT(&htim6);

the Working example generates a tone, while the NotWorking example doesn't

Additional context

If you have a first analysis or patch correction, thank you to share your proposal.

I am not 100% the execution order of the two _Init() functions is supposed to matter. If it is supposed to matter, document it and fix the code generator. If it is not supposed to matter, fix the _Init() functions.

[ASELSTM]

Hi @giuliomoro,

Thank you for this report. The point you reported is actually related to the CubeMX generation problem and not to the firmware published in this repository. Unfortunately, we don't treat aspect related to CubeMX tool in our GitHub repositories. They are rather treated at the STM32CubeMX dedicated page of the ST Community .

Since this issue is not directly related to the STM32Cube firmware but rather to our ecosystem, please allow me then to close this thread. Thank you for your comprehension.

With regards,

[ASELSTM]

ST Internal Reference: 111780