STM32H7RS HAL: IS_SPI_LIMITED_DATASIZE rejects 9-bit on SPI4/SPI5, but RM0477 says 4–16 bits are supported

[macosali]

Hello,

I am using an STM32H7S3 with STM32CubeH7RS HAL [V1.2.1]. SPI5 drives a display over 3-wire SPI with 9-bit frames (the 9th bit carries D/C).

With USE_FULL_ASSERT enabled, HAL_SPI_Init() triggers an assert in stm32h7rsxx_hal_spi.c (line 259 in the current GitHub version):

if (IS_SPI_LIMITED_INSTANCE(hspi->Instance))
{
  assert_param(IS_SPI_LIMITED_DATASIZE(hspi->Init.DataSize));
  assert_param(IS_SPI_LIMITED_FIFOTHRESHOLD(hspi->Init.FifoThreshold));
}

In stm32h7rsxx_hal_spi.h, the macro only accepts 8-bit and 16-bit:

#define IS_SPI_LIMITED_DATASIZE(DATASIZE)  (((DATASIZE) == SPI_DATASIZE_16BIT) || \
                                            ((DATASIZE) == SPI_DATASIZE_8BIT))

However:

1. RM0477 [rev 10], section 55.3, Table 578 states that for SPI4 and SPI5 the data and CRC size is "configurable from 4 to 16 bits".

2. The HAL itself is inconsistent. A few lines below the assert, the runtime check in HAL_SPI_Init() only rejects sizes above 16 bits for limited instances:

if ((IS_SPI_LIMITED_INSTANCE(hspi->Instance)) && (hspi->Init.DataSize > SPI_DATASIZE_16BIT))
{
  return HAL_ERROR;
}

3. In practice, init succeeds with SPI_DATASIZE_9BIT and the display works correctly. [Optional: A logic analyzer capture shows 9 SCK pulses per frame.]

For comparison, the same macro in the STM32U5 and STM32H5 HAL also accepts only 8/16 bits, which matches RM0456 (DSIZE[2:0] reserved on limited instances). The STM32N6 HAL accepts the full 4–16 bit range. It looks like the H7RS macro was carried over from U5/H5, while the H7RS hardware behaves differently.

Small side note on Table 578: the SPI4/SPI5 column header also says "full-featured instances", although the values in that column are clearly the limited ones. The FIFO threshold row says 1–16 data for an 8x8-bit FIFO, while the HAL limits it to 8 data and checks the packet size against 8 bytes.

Questions:
- Can ST confirm that SPI4/SPI5 on STM32H7RS officially support all data sizes from 4 to 16 bits?
- If so, could IS_SPI_LIMITED_DATASIZE be updated to accept SPI_DATASIZE_4BIT to SPI_DATASIZE_16BIT in a future release?
- Could the Table 578 header and FIFO threshold row be reviewed?

Thank you.

[macosali]

Update: I found a second limited-instance check with the same root cause, this time on SPI4, which drives an external SPI flash.

 

In stm32h7rsxx_hal_spi.h, the transfer size for limited instances is capped at 1022:

 

  #define IS_SPI_LIMITED_TRANSFER_SIZE(SIZE) (((SIZE) < 0x3FFU) && ((SIZE) != 0U))

  #define IS_SPI_TRANSFER_SIZE(SIZE) (((SIZE) < 0xFFFFU) && ((SIZE) != 0U))

 

IS_SPI_LIMITED_TRANSFER_SIZE is asserted in all nine transfer functions (HAL_SPI_Transmit, HAL_SPI_Receive and HAL_SPI_TransmitReceive, in their blocking, IT and DMA variants). However, RM0477 Table 578 (the same table as in my first post) states "Number of data control (TSIZE): up to 65535" for SPI4 and SPI5.

 

Test on hardware: with the assert bypassed, a 4096-byte transfer on SPI4 completes correctly with EOT, and the data read back from the flash matches what was written. This is a meaningful check, because 4096 = 0x1000 has all lower 10 bits cleared. If TSIZE were only 10 bits wide on SPI4, the hardware would see TSIZE = 0 (endless transfer) and EOT would never be set.

 

The pattern is the same as for IS_SPI_LIMITED_DATASIZE: the STM32U5 and STM32H5 HAL use the same < 0x3FF limit, while the STM32N6 HAL uses < 0xFFFF for limited instances as well.

 

Minor side note: both macros use a strict < comparison, so the boundary values themselves (1023 and 65535) are also rejected, although TSIZE can hold them.

 

Additional question:

- Can ST confirm that TSIZE on SPI4/SPI5 of STM32H7RS is a full 16-bit field, and could IS_SPI_LIMITED_TRANSFER_SIZE be aligned with RM0477 in a future release?

 

Thank you.

[Saket_Om]

Hello ​@macosali 

Thank you for bringing this issue to our attention.

I reported this internally.

Internal ticket number: CDM0066202 (This is an internal tracking number and is not accessible or usable by customers).

[macosali]

Hello.

Thanks lot.

Could you also check this  DSB Solve

This is also from our team.