Skip to main content
MKidd.1
MKidd.1
Associate
August 31, 2021
Solved

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?

  • August 31, 2021
  • 16 replies
  • 3739 views

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?

This topic has been closed for replies.
Best answer by 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 */

16 replies

TDK
TDK
August 31, 2021

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

"If you feel a post has answered your question, please click ""Accept as Solution""."
MKidd.1
MKidd.1Author
Associate
August 31, 2021

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
TDKBest answer
August 31, 2021

> 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 */

"If you feel a post has answered your question, please click ""Accept as Solution""."
MKidd.1
MKidd.1Author
Associate
August 31, 2021

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!

Terms & ConditionsAccessibility statement