CubeIDE 1.7.0 programming Nucleo-H723ZG to respond to UART input using DMA receive. Code generated by MX results in received data ec as all zeros. Is this a known MX-generated code error?

[MKidd.1]

The MX generated C code issues the USART initiation call before the DMA initiation call. My code simply echoes back any text received by the USART. Unfortunately the echoed data (correct length) is all zeros. The UART read buffer is initialised with zeros.

The issue is resolved by simply placing the DMA initiation call before the USART initiation call!

What’s going on? Looks like the DMA code upsets something set by the USART code, but what?

[TDK]

Longstanding issue that ST got right in older versions of CubeMX.

Lots of other threads on it as well:

https://community.st.com/s/question/0D50X0000C0xoFxSQI/bug-cubemxcubeide-ignores-changes-in-initialization-order

[MKidd.1]

Thanks for this TDK. I assume from your response that in certain cases, such as this one, the sequence of initiations is critical. Are you able to tell me just why that is the case here; a casual look at the generated code doesn’t provide any obvious answers.

[TDK]

> I assume from your response that in certain cases, such as this one, the sequence of initiations is critical.

Mainly just this one (DMA), I think. But there may be others.

> Are you able to tell me just why that is the case here

The UART initialization modifies a DMA register, which needs the DMA clock to be active. The clock is activated in the DMA initialization.

For what it's worth, CubeMX generated the correct order on a fresh project for me. It's possible you're not on the latest version or something else is going on.

 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_DMA_Init();
 MX_ETH_Init();
 MX_USART3_UART_Init();
 MX_USB_OTG_HS_USB_Init();
 /* USER CODE BEGIN 2 */

[MKidd.1]

That’s an excellent answer, thank you TDK. I’m using CubeIDE v 1.7.0 which is the latest version so something else must be at play!