HAL_SPI_TransmitReceive_DMA not written correctly by CubeMX

[btd5]

I am using SPI with DMA as shown in the screenshot. DMA is using Data Handling to truncate data from SPI's 16bit buffer into 8 bit values.

The following part of the code errors out. Commenting this code out makes my application work, but every time I change things in CubeMX it is rewriten. Why does this check even exist?

/* Packing mode management is enabled by the DMA settings */
if (((hspi->Init.DataSize > SPI_DATASIZE_16BIT) && (hspi->hdmarx->Init.DestDataWidth != DMA_DEST_DATAWIDTH_WORD) && \
(IS_SPI_FULL_INSTANCE(hspi->Instance))) || \
((hspi->Init.DataSize > SPI_DATASIZE_8BIT) && (hspi->hdmarx->Init.DestDataWidth == DMA_DEST_DATAWIDTH_BYTE)))
{
/* Restriction the DMA data received is not allowed in this mode */
errorcode = HAL_ERROR;
/* Unlock the process */
__HAL_UNLOCK(hspi);
return errorcode;
}

 

[Tesla DeLorean]

Why'd you read the peripheral as 16-bit wide, and try and push that out as 8-bit?

The peripheral should be able to decode the width of the access.

Is the SPI in 16-bit mode? If not just be consistent across the board.

[btd5]

I am using this SPI to talk to LIS3DHTR accelerometer. I transmit using

HAL_SPI_TransmitReceive_DMA(&hspi1, (uint8_t*) ACC_READ_ALL_DMA,

                                                      (uint8_t*) (acc_value+acc_value_cnt), 32*3);

to get 32 readings, each being 8 bit x 3 axis. ACC_READ_ALL_DMA is a 96 long table, with 0xE900,0,0 repeating. acc_value is a large buffer to store data. The responses start with one garbage byte (which is truncated by DMA), then there are 191 bytes, of which half are usefull data, the other half (should in theory be) zeros. Since I want to store a lot of values, I want the output to be only the usefull data, without the zeros, so I use Data Handling functionality. The CPU only has to wake up to start the DMA, reducing power consumption, and data is automaticaly transfered and condensed.