Possible STM32CubeMX 6.16.1 code generation issue with SAI GPDMA Circular Mode on STM32H7R3

[moreto]

Hello,

I would like to report what appears to be a code generation issue in STM32CubeMX 6.16.1.

My configuration is:

• MCU: STM32H7R3
• STM32CubeMX: 6.16.1
• STM32Cube FW_H7RS: 1.3.0
• SAI2 Block A configured as Master TX
• SAI2 Block B configured as Synchronous RX
• GPDMA channels 10 and 11 configured in Standard Request Mode and Circular Mode
   

The generated HAL code internally creates a linked list with a single node for each DMA channel. In the generated sai.c file I get:

DMA_NodeTypeDef Node_GPDMA1_Channel11;

DMA_NodeTypeDef Node_GPDMA1_Channel10;

However, these DMA node structures are not placed in a non-cacheable memory region.

If I instead use the LinkedList Utility and configure the channels in Linked List Mode, CubeMX generates:

DMA_NodeTypeDef Node_SAI2_A __attribute__((section("noncacheable_buffer")));

DMA_NodeTypeDef Node_SAI2_B __attribute__((section("noncacheable_buffer")));

The "noncacheable_buffer" section is defined in the linker script in a memory region accessible by the GPDMA and I configured it in the MPU as non-cacheable.

With the code generated for Circular Mode, the DMA transfer does not start correctly and:

HAL_SAI_Transmit_DMA(...)

returns HAL_TIMEOUT.

After manually moving the generated DMA nodes to the same non-cacheable section:

DMA_NodeTypeDef Node_GPDMA1_Channel11 __attribute__((section("noncacheable_buffer")));

DMA_NodeTypeDef Node_GPDMA1_Channel10 __attribute__((section("noncacheable_buffer")));

the SAI full-duplex DMA starts working correctly.

From my understanding, even though the GPDMA channels are configured in Standard Request Mode, the HAL implementation still relies on DMA linked-list nodes internally. Therefore, these node descriptors should probably be placed in non-cacheable memory just like the nodes generated by the LinkedList Utility.

Is this a known issue in STM32CubeMX 6.16.1 / STM32Cube FW_H7RS v1.3.0?

If this behavior is expected, I think it should at least be documented somewhere. I spent many hours debugging the SAI and GPDMA configuration before discovering that the only issue was the memory placement of the DMA node structures.

Hopefully this information will help others avoid the same issue and save some debugging time.

Best regards,

Miguel

[Souhaib MAZHOUD]

Hello ​@moreto 

Can you provide an IOC in order to investigate this behavior.

KR, Souhaib

[moreto]

Hello ​@Souhaib MAZHOUD,

Yes, no problem. Please find attached the .ioc file that I am using.

I am not using the Linked-List Utility at the moment. Although it correctly allocates the GPDMA node structures in the .noncacheable_buffer region, I couldn't make it work. Therefore, I am using the Standard Request Mode for the GPDMA channels instead.

With this mode, the node structures are not allocated in the .noncacheable_buffer region, so I have to change the allocation manually. Unfortunately, this change is overwritten every time I regenerate the code with CubeMX.

[Souhaib MAZHOUD]

Hello ​@moreto 

Thanks for your explanation,
I noticed that when I uncheck the option "Generate peripheral initialization as a pair of '.c/.h' files per peripheral" in Project Manager > Code Generator, the generated code places the DMA node structures in a non-cacheable memory region, as shown below:

DMA_NodeTypeDef Node_GPDMA1_Channel11 __attribute__((section("noncacheable_buffer")));
DMA_NodeTypeDef Node_GPDMA1_Channel10 __attribute__((section("noncacheable_buffer")));

I will verify this behavior internally with the team to confirm whether it is a known issue with code generation options.

BR, Souhaib

[Souhaib MAZHOUD]

Hello ​@moreto 

This issue has been escalated to dedicated team for further investigation and fix: Internal ticket number: CDM0064377 (This is an internal tracking number and is not accessible or usable by customers.)

BR, Souhaib

[moreto]

Hello ​@Souhaib MAZHOUD 

Thank you very much!

Best regards! 

Moreto