cancel
Showing results for 
Search instead for 
Did you mean: 

SPI problem with STM32L496 and package 1.13.0

SStor
Senior

Hello,

after updating STM32Cube​MX 4.27.0 with package 1.13.0 for STM32L4 I have a problem with SPI communication. I've replaced the file stm32l4xx_hal_spi.c with the old from 1.12.0 and it works.

Can you check if there is any bug in stm32l4xx_hal_spi.c in v1.13.0?

Thank you!

5 REPLIES 5
Imen.D
ST Employee

Hello,

Can you please provide the exact error: localize where the code hangs/stop and the kind of message gives.

If possible, share your ioc file for check this case and identify what is going wrong.

Kind Regards,

Imen

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen
SStor
Senior

Hello,

I think my problem is the function HAL_SPI_Abort() in the following line:

Code in v1.12 works correct:

 /* Disable the SPI DMA Tx or SPI DMA Rx request if enabled */

if ((HAL_IS_BIT_SET(hspi->Instance->CR2, SPI_CR2_TXDMAEN)) || (HAL_IS_BIT_SET(hspi->Instance->CR2, SPI_CR2_RXDMAEN)))

Code in v1.13 works not correct:

 /* Disable the SPI DMA Tx or SPI DMA Rx request if enabled */

if ((READ_BIT(hspi->Instance->CR2, (SPI_CR2_TXDMAEN | SPI_CR2_RXDMAEN))) == (SPI_CR2_TXDMAEN | SPI_CR2_RXDMAEN))

I use SPI only in TX or RX mode so I think this change in the new firmware could cause a different behaviour? Can you check this?

Thank you in advance!

EMaku
Associate

I am having a similar issue. With HAL V1.12 SPI communication with a SX1272 works fine, but after upgrading to v1.13 I am getting bogus data from the device.

    HAL_GPIO_WritePin(SX1272_CS_GPIO_Port,SX1272_CS_Pin,GPIO_PIN_RESET);
    if(HAL_SPI_TransmitReceive(&hspi1, message_tx, message_rx, 2, 5000) == HAL_OK) {}
    HAL_GPIO_WritePin(SX1272_CS_GPIO_Port,SX1272_CS_Pin,GPIO_PIN_SET);

With v1.12 I am getting the correct value (0x22) from the SX1272 version register. On v1.13 I am getting 0x11 which is wrong.

SStor
Senior

Hello,

seems to be a bitshift of 1 bit in your case (0x22 >> 1 = 0x11). Perhaps one bit from previous transmission could be in SPI bitshift buffer yet, so successive characters will be mixed.

I've compared the file stm32l4xx_hal_spi.c from v1.13 with the file from v1.12 and discovered a lot of changes, probably for supporting also the new STM32L4+ series with this package.

In my case there is a bug in function HAL_SPI_Abort definitely (function not executed in SPI receive only mode) and I solved the problem with exchanging the stm32l4xx_hal_spi.c with the old from 1.12 manually in Drivers subdirectory.

Maybe that there are further problems existing. I'm hopeful waiting for a new v1.14 now...

Imen.D
ST Employee

Hello,

We confirm the problem with HAL_SPI_Abort during SPI communication in TX or RX only mode.

This issue will be fixed in the coming version of STM32CubeL4 firmware package.

Thanks and Best Regards,

Imen.

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen