cancel
Showing results for 
Search instead for 
Did you mean: 

Bug in CubeMX code generation for SPI/DMA

crwper
Senior

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.
1 ACCEPTED SOLUTION
2 REPLIES 2
crwper
Senior

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.