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?

16 REPLIES 16

Ahhh, reading the link you sent at the beginning "BUG: CubeMX/CubeIDE ignores changes in initialization order" it appears that I should have gone into the MX project manager->advanced settings to change the order. After moving the DMA init() behind the USART init() and re-generating the code the init sequences are then in the correct order. Is this something the programmer has to have knowledge of - the correct order of the MX initialisation functions? Wow!!

Our files are identical except for this line, which appears to dictate the initialization order:

ProjectManager.functionlistsort=1-MX_GPIO_Init-GPIO-false-HAL-true,2-SystemClock_Config-RCC-false-HAL-false,3-MX_ETH_Init-ETH-false-HAL-true,4-MX_USART3_UART_Init-USART3-false-HAL-true,5-MX_DMA_Init-DMA-false-HAL-true,6-MX_USB_OTG_HS_USB_Init-USB_OTG_HS-false-HAL-true,0-MX_CORTEX_M7_Init-CORTEX_M7-false-HAL-true

> Is this something the programmer has to have knowledge of - the correct order of the MX initialisation functions?

It wouldn't hurt, but CubeMX should generate it correctly. Not sure why the behavior is different between our systems.

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

Well I think that you've taken it as far as is possible, TDK, thank you; and for introducing me to a more detailed look at the MX configurator, as well as providing an explanation of a rather time-consuming and infuriating puzzle.

So, in conclusion, am I correct in understanding you to say that (presumably) on Windows, using the latest version of CubeIDE a programmer setting up a DMA USART receive capability does not have to concern herself with the intricacies of the operation as the code generator recognises this and ensures the DMA initialisation precedes that of the USART?

Correct.
However, especially in programming and electronics, things often don't work out exactly as expected and debugging skills are a necessary part of the job.
CubeMX does a good job of doing most of the work for you, but it's just a tool and every scenario isn't tested, it has bugs, etc. It's an excellent tool (especially now that it has matured a few years), but don't expect perfection.
If you feel a post has answered your question, please click "Accept as Solution".

Agreed!

I’ve been using another board recently (rather than my Nucleo-H723ZG). This board, a Nucleo-H743ZI2, does not present any initialisation sequence error when using USART with DMA.