Is it reasonable for HAL library SPI to judge RXP in blocking receive 8bit mode? Again, because of the old code to determine the RXWNE/FRLVL flag

[wdfk-prog]

Describe the set-up

• ART-PI STM32H750
• KEIL5 AC6 v6.19 -oz

Additional context

• My English is not very good, the following information is translated by software.

The cause of the problem

• Symptom SPI FLASH reported an error after HAL library version was updated from V1.10 to V1.11
  
• The problem code is found in the HAL_SPI_TransmitReceive function on the 8 Bit mode transmitreceive flag.The code of SPI.C has been changed to V1.11, and the only problem has been changed to V1.10 judgment.HAL library code for V1.10.
  
• Here's the difference

      /* Wait until RXWNE/FRLVL flag is reset */
      if (((hspi->Instance->SR & (SPI_FLAG_RXWNE | SPI_FLAG_FRLVL)) != 0UL) && (initial_RxXferCount > 0UL))
      {
        *((uint8_t *)hspi->pRxBuffPtr) = *((__IO uint8_t *)&hspi->Instance->RXDR);
        hspi->pRxBuffPtr += sizeof(uint8_t);
        hspi->RxXferCount--;
        initial_RxXferCount = hspi->RxXferCount;
      }

• V1.11 version of the HAL library code
  
• The main difference is in the judgment of the receiving flag.Judging V1.10 SPI_FLAG_RXWNE | SPI_FLAG_FRLVL.
• V1.11 Judging SPI_FLAG_RXP.The actual DEBUG entry found that only the FRLVL flag was triggered, but not the RXP flag.
  

Screenshots
If applicable, add screenshots to help explain your problem.

[HBOSTM]

Hello @wdfk-prog,

Would you please give us more details about how you got this issue? And please share snippet of the code you have used to reproduce this problem.

With regards,

[wdfk-prog]

Hello @HBOSTM ,

• I used the following function to enter

https://github.com/RT-Thread/rt-thread/blob/master/bsp/stm32/libraries/HAL_Drivers/drv_spi.c#L393

I'm not sure what other details need to be provided, what is the state of the register when it enters?Or the way to use it?

[fandelxin]

HAL library version updated from V1.10 to V1.11. I have the same problem. If the data in flash (W25Q) is read continuously through SPI, there is a certain probability that it will timeout. The timeout is in this place "HAL_SPI_Receive ->if (__HAL_SPI_GET_FLAG (hspi, SPI_FLAG_RXP)"

[axbusch]

the new SPI H7 driver also has a problem with optimization & blocking mode

i used the old driver for stm32f4 without any problems in Keil armclang 6 with o1, o2, or o3. No Problem.

The new driver works only with o0. i think there is something optimized away(missing volatile or sth like that)
i will try to reproduce and dig deeper to provide more information

[escherstair]

Hello @ASELSTM, @HBOSTM, @TOUNSTM
I can add some information from my side, in case it helps.
I have a code that works on STM32H7 with library V1.10 and that doesn't work anymore after the upgrade to V1.11.
It's compiled with ARMCLANG 6, with O1 optimization, so similar to what @fandelxin described in his post.
I use TransmitAndReceive in blocking mode, 8 bit, as described by @wdfk-prog

This is what my code does, and what I see with library V1.11:

• I have a MEMS sensor (iis3dwb) that continously generates a GPIO interrupt of "data ready"
• the interrupt handler triggers a FreeRTOS task that reads the data from the MEMS through SPI3
• when I want to write other data into an external SPI EEPROM using SPI4 I trigger a different FreeRTOS task
  When this happens, the "SPI3" task has some issues (not sure what kind of issues, I need more investigation).
  I imagine it's delayed (or blocked) because the MEMS doesn't see its data read away and it gives error.

I had to downgrade to V1.10 and this is a showstopper for my project.
I need a fix as soon as possible.

Let me know if I can do something in my investigation to help the team.

[escherstair]

Hi @HBOSTM
do you need some other detailon the issue, or is it clear?
@wdfk-prog , @fandelxin , @axbusch do you have any news in the meanwhile?

This issue is a showstopper for me, and I had to downgrade

[undisclosed67]

Regrettably, I am experiencing similar issues with the SPI peripheral, after upgrading to FW Package v1.11.1.
I am not able to investigate further at this time, but I had it working again by reverting both stm32h7xx_hal_spi.c and stm32h7xx_hal_spi.h to version v1.10.
I would like to thank the ST team for the hard work put into this. I know what it means.

[escherstair]

I can give an update on my issue (not sure if this is the same for the others).

• I have two devices connected on different SPI peripherals (SPI3 and SPI4)
• I configured SPI interrupt priority to the same value (5) for both of them
• this works with FW package V1.10 and doesn't work with firmware V1.11.0 (and V1.11.1)
• I set the SPI interrupt priority to 7 for one of the peripherals

  #define MX_SPI3_IRQn_interruptPremptionPriority 7
  #define MX_SPI4_IRQn_interruptPremptionPriority 5

• this works with FW package V1.10, V1.11.0 and V1.11.1

Not sure why this happened.

[KRASTM]

Hello All,

thank you for your Reports.

@wdfk-prog: the issue has already been fixed internally, and it will be available on the next release of STM32CubeH7 Firmware.

Regarding the problem with the function HAL_SPI_Receive(), Please refer to last comment 47

With regards,

[KRASTM]

ST Internal Reference: 172042

[wdfk-prog]

大家好，

感谢您的报告。

@wdfk-prog：该问题已在内部修复，并将在下一版本的 STM32CubeH7 固件中提供。

关于函数HAL_SPI_Receive()的问题，请参考最后评论47

带着敬意，

• So, how can you change the code in older versions to prevent this problem?

[KRASTM]

Hello @wdfk-prog,

Attached the update files, but please be careful because it contains many changes. It may cause some errors while building your project. In that case, you must wait for the release (which will be available after a few days).

Otherwise, I hope it will be useful and good luck.

H7_HAL_SPI.zip

With regards.

[TOUNSTM]

Fixed in abbf9ca