CubeMX 5.4.0 Generates broken code for STM32H7 STM32H7432 SAI DMA

[caleb]

The latest version (5.4.0) of CubeMX (and who knows... maybe every version before) generates DMA initialization code out of order, and it's kind of hard to diagnose until you single step through all the HAL code.

I am using an STM32H743 and setting up circular DMA for the SAI port.

The code generated in main.c looks like this:

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_SAI1_Init();
  MX_SAI2_Init();
  MX_I2C2_Init();
  MX_SPI2_Init();
  MX_USB_DEVICE_Init();
  MX_I2S1_Init();
  MX_SDMMC2_SD_Init();
  MX_DMA_Init();

The DMA for the SAI ports gets configured in MX_SAI1_Init() and MX_SAI2_Init(). Unfortunately, since MX_DMA_Init() is called AFTER the MX_SAIx_Init(), none of the SAI DMA settings get configured right, and it just doesn't work, and you spend a day or two debugging the CubeMX code. Ugh.

So, the solution is to go to Project Manager->Advanced Settings, and disable the init calls by clicking 'NOT Generate Function Call' for all the init functions, and create your own function that calls them in the right order, like this:

  void local_setup()
  {
    MX_DMA_Init();
    MX_GPIO_Init();
    MX_SAI1_Init();
    MX_SAI2_Init();
    MX_I2C2_Init();
    MX_SPI2_Init();
    MX_USB_DEVICE_Init();
    MX_I2S1_Init();
  }

No question here... just posting in case somebody else has the same problem. This is, of course, a totally different issue from the memory access/DMA issues with the data case and the DTCM.

If the reader ended up here because of DMA not working with CubeMX, there are (at least) 3 things that you need to deal with:

1. You must put your DMA buffers in D2 or D3 memory, which requires you change linker script to include a D2 ram section and then put your buffer there and follow the instructions found elsewhere on how to do that. This is because the SAI's DMA can't reach the default memory space which is in the DTCM (Data tightly coupled memory)
2. You must do cache invalidation/flushing/disabling as documented elsewhere in STM32H7 DMA doesn't work posts.
3. And the undocumented part is here: you must rearrange the init calls as above because CubeMX generated DMA code is un-tested and doesn't work

-Caleb

[caleb · Accepted solution]

Ah! I found the secret, magic buttons that allow you to re-order the functions calls.

First of all, the tool should always put DMA first so that the generated code can work. However, you can, if you like, change the order of function calls by doing some magic-difficult-scrolling, finding the completely hidden buttons, and changing the ranking like this:

Maybe scroll down?

Oh wait... is that another, nearly invisible, scrollbar to scroll left and right? What about that?

[Piranha]

Non-ergonomic, ugly and full of bugs - they call it "modern UI". That's what we get, when dumb code monkeys are reinventing the wheel.

[caleb]

So, not just me :)

[eeyurdakul]

Hi caleb,

I am also suffering I2S DMA on STM32H743. Polling & IT modes are working perfectly. But DMA mode halts whenever it starts.(I make it work in F4 & F7). As I see from your code, you are also using I2S in your project. Could you able to make it work? If so, could you share your knowledge please? (if you could share the code, I would really be pleased) Thanks

[caleb]

I haven't gotten to the I2S yet, just the SAI so far. Got pulled to another project. Are you sure that you understand and have dealt with all 3 issues I mentioned above? Namely:

If the reader ended up here because of DMA not working with CubeMX, there are (at least) 3 things that you need to deal with:

1. You must put your DMA buffers in D2 or D3 memory, which requires you change linker script to include a D2 ram section and then put your buffer there and follow the instructions found elsewhere on how to do that. This is because the SAI's DMA can't reach the default memory space which is in the DTCM (Data tightly coupled memory)
2. You must do cache invalidation/flushing/disabling as documented elsewhere in STM32H7 DMA doesn't work posts.
3. And the undocumented part is here: you must rearrange the init calls as above because CubeMX generated DMA code is un-tested and doesn't work

[ALant.1]

Thank you caleb for finding those magic buttons! This is really weird, took me 14h reading forums and docs to realize that there is bad initialization order taking place...