Bug in SPI Transmit ?

Hello @anio1491​ ,

Thanks for reporting this issue. We will check this internally and come back to you with update.

Kind Regards,

Imen

I think that the condition should be

if ( ( hspi->Init.DataSize == SPI_DATASIZE_16BIT ) 

Version 1.11 has many spots with the condition:

|| ((hspi->Init.DataSize <= SPI_DATASIZE_8BIT) && (Size > 1U))

This is a common optimization in the HAL library. It uses 16-bit writes to the DR as long as there are at least 2 bytes left in the buffer. This reduces the number of writes, and reduces any delays between bytes on the SPI bus. However, it does require that the data buffer be aligned on a 16-bit boundary, as you've seen. The GCC compiler appears to force alignment of arrays to 32-bit boundaries (at least when compiling for the 32L4xx series). So I'm guessing you hit this when you pass a buffer pointer that isn't at the beginning of the buffer's allocated memory. For example:

MyFunc()
{
 uint8_t buf[50]; // buf[0] SHOULD be aligned to 32-bit address
 
 ... fill 11 bytes in buf[] starting at [0]
 HAL_SPI_Transmit( hspi1, buf, 11, 5000 ); // Send 11 bytes, works OK
 
 ,.. Append more data in buf[11] to buf[20]
 HAL_SPI_Transmit( hspi1, &buf[11], 10, 5000 ); // Fails, not aligned
}

Hmmm... why optimize bus access if it pushes the 16 bit alignment constrain up the application level?

sending 1 byte by SPI will take 16+ SYSCLK so we are talking optimizing 1 cycle over 32+

If the communication is polling (blocking), it's just not worth the complexity?

Newer STM32 have FIFO HW in the SPI to solve partially this "limitation" such as in the STM32L496.

Hello,

We confirm issue on L0 as SPI IP vesion is not supporting the data packing. So, in this particularity case, we can just check alignment when data size is equal to 16bit.

On STM32F0, who is also using a cortex M0, this assert cannot be modify as SPI IP version is not the same and Data packing is used. So even if we are in 8 bit, a 16bit transfer is performed for Performances.

Best Regards,

Imen