Shouldn't DMA_HandleTypeDef State be volatile?

[DavidAlfa]

Current structure is:

typedef struct __DMA_HandleTypeDef
{
 ...
HAL_DMA_StateTypeDef State;              /*!< DMA transfer state           */              
...
} DMA_HandleTypeDef;

Interrupts can change the State value, but it's not volatile, so the compiler is unaware.

Polling the handler state until it changes to HAL_DMA_STATE_READY will fail when optimizations are enabled.

This works perfectly:

typedef struct __DMA_HandleTypeDef
{
 ...
__IO HAL_DMA_StateTypeDef State;              /*!< DMA transfer state           */              
...
} DMA_HandleTypeDef;

[TDK]

Yes, it should. What chip?

It's defined as volatile for the H7 series:

https://github.com/STMicroelectronics/STM32CubeH7/blob/ccb11556044540590ca6e45056e6b65cdca2deb2/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_hal_dma.h#L145

[DavidAlfa]

32F103C8, using FW F1 v1.8.4​ library.

Definitely not in the F1​ library, issued a pull request:

https://github.com/STMicroelectronics/STM32CubeF1/pull/36/commits/4ba3ef94f1d79bd33541f177fd548d4a605dc67a

[Piranha]

For this purpose the user is supposed to call the HAL_DMA_GetState() function, which will not have the optimization problem.

Also the Lock member of the structure must be volatile for the compiler to not mess up the access order for these variables.

And they are changing the variables ErrorCode and State after the __HAL_UNLOCK(), which creates a race condition:

https://github.com/STMicroelectronics/STM32CubeH7/blob/ccb11556044540590ca6e45056e6b65cdca2deb2/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_dma.c#L839

Not counting the ones in HAL_DMA_Init(), which are most likely "by design", they to this after the lines: 656, 752, 839, 877, 949, 1177, 1328, 1373, 1405, 1513, 1541.