Bug in CubeMX code generation for SPI/DMA

[crwper]

I think I have discovered a bug in the way CubeMX behaves when both SPI and DMA are enabled. I am using the P-NUCLEO-WB55 board. If you look at the SPI_FullDuplex_ComDMA_Master example application, this runs fine on the P-NUCLEO-WB55 with a jumper between MISO and MOSI. However, if you exchange two lines in main.c so that we have:

MX_GPIO_Init();
MX_SPI1_Init();
MX_DMA_Init();

instead of:

MX_GPIO_Init();
MX_DMA_Init();
MX_SPI1_Init();

then the example fails. However, this is exactly what CubeMX does if we follow these steps:

1. Create a new project for the P-NUCLEO-WB55-Nucleo (do not initialize peripherals in default mode)
2. Enable SPI1 as full duplex master with SPI1_SCK on PA6
3. Save and generate code
4. Add SPI1_RX and SPI1_TX DMA requests
5. Save and generate code

The problem does not occur if we don't save and generate code after enabling SPI1, i.e.:

1. Create a new project for the P-NUCLEO-WB55-Nucleo (do not initialize peripherals in default mode)
2. Enable SPI1 as full duplex master with SPI1_SCK on PA6
3. Add SPI1_RX and SPI1_TX DMA requests
4. Save and generate code

In this case, the system correctly calls MX_DMA_Init() before MX_SPI1_Init(). I see two possible solutions to the problem:

1. Either ensure that CubeMX generates these two lines in the correct order always, or
2. Modify the code in MX_DMA_Init() and MX_SPI1_Init() so that they do not depend on the order in which they are called.

[Piranha · Accepted solution]

https://community.st.com/s/question/0D50X0000Bmob3uSQA/dma-not-working-in-cubemx-generated-code-order-of-initialization

[crwper]

Thanks! The workaround at the top of that thread did the trick for me, though I had to be a bit clever to get the IDE to save the new settings--the save buttons remained grayed out even after I changed the initialization order, so I had to change/revert a pin assignment.