cancel
Showing results for 
Search instead for 
Did you mean: 

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
Associate II

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?

1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Guru

> 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".

View solution in original post

16 REPLIES 16
TDK
Guru

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".

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
Guru

> 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".

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!

0693W00000Dln4DQAR.jpg

FYI, TDK: The above was code generated by CubeIDE v 1.7.0 for a Nucleo-H723ZG. The only thing I did to the default configuration was to add DMA receive to the USART!

Same with me. Can you attach your IOC file? Gotta be an answer.

If you feel a post has answered your question, please click "Accept as Solution".

Will do tomorrow - it’s late here in UK!

TDK, here's the .loc file you requested. BTW I am running the CubeIDE 1.7.0 on a late 2015 iMac under MacOS Big Sur 11.5.2.

Good luck!