Is there a possible bug in function HAL_SPI_Transmit_DMA() (STM32Cube_FW_H7_V1.3.0)?

[ddl22]

Hi everyone!

I'm trying to transmit some data using SPI2 on a NUCLEO-H743ZI board (only TX). To do it fast I'm using DMA with HAL_SPI_Transmit_DMA(), but it returns with an error (from line 1465 in stm32h7xx_hal_spi.c):

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

After replacing 'hdmarx' to 'hdmatx' (as I'm only trying to transmit some data and I'm not interested in receiving) it works as it supposed to.

Is this a possible bug, or am I just lucky to make it work somehow (I'm new to HAL)?

[Amel NASRI]

Hello @Balázs Ölvedi​ ,

As you are using SPI in transmission mode, you need to configure SPI Tx DMA Handle parameters.

You are right, this is an error in the driver that I'll report internally.

-Amel

[GreenGuy]

I am doing the same thing (STM32H743, SPI DMA transfer) except I am using transmit and receive (Master mode, full duplex).  I have set both tx buffer and rx buffer as 32 byte aligned.  My code is falling out at the same place, but now it is at line 2324 :

 

/* Restriction the DMA data received is not allowed in this mode */

errorcode = HAL_ERROR;

I notice that the check is still being made with respect to hspi->hdmarx.

So is this still a bug? I tried pointing to ->hdmatx but that does change the error.

[GreenGuy]

I went back to my original test bench for this code which used a STM32G0xx and an Arty-7 board, testing spi communication between STM32 and Xilinx Series 7 FPGA.  It works fine using Full-Duplex DMA.  The STM32G0xx HAL code for  HAL_SPI_TransmitReceive_DMA() is very different and the alignment checks are performed in a more broken out manner with checks made with multiple if statements depending on the SPI mode in use.

 

[ddl22]

Also found a typo in stm32h7xx_hal_spi.h at line 699:

//Line 687:
/** @brief Clear the SPI UDR pending flag.
 * @param __HANDLE__: specifies the SPI Handle.
 * @retval None
 */
#define __HAL_SPI_CLEAR_UDRFLAG(__HANDLE__) SET_BIT((__HANDLE__)->Instance->IFCR , SPI_IFCR_UDRC)
 
 
//Line 699:
/** @brief Clear the SPI UDR pending flag.
 * @param __HANDLE__: specifies the SPI Handle.
 * @retval None
 */
#define __HAL_SPI_CLEAR_TXTFFLAG(__HANDLE__) SET_BIT((__HANDLE__)->Instance->IFCR , SPI_IFCR_TXTFC)

I'm guessing the comment should say: "Clear the SPI TXTF pending flag".

[Amel NASRI]

Thanks for sharing your finding. We will take care to fix it.

-Amel

[Piranha]

https://github.com/STMicroelectronics/STM32CubeH7/blob/dd1b1d7144e6c61f995a368bbbeaad1936d60cd1/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal_spi.c#L2319-L2320

These two lines and other code in HAL drivers have a backslash at the end of line. This shows that the person, who wrote it, doesn't even understand the difference between C code and preprocessor macros.

Edited by moderators to adhere to community guidelines.

[GreenGuy]

OK not a bug, but simply not aware of everything to touch.  In CubeMx the DMA selection for the SPI I am using needs to be configured as HALF_WORD.  This sets the DMA_MDATAALIGN_xxxx parameter.  Not sure with all the error checking that CubeMx does why it would allow 16 bit in the SPI setup and then align DMA as Byte which causes the HAL_ERROR.

 

[GreenGuy]

So is that a feature request and not a bug?