STM32U031 SPI receive data of arbitrary length

[FlokRo]

Greetings!
I am using the STM32U031 with STM32CubeMX HAL as an SPI Slave and would like to receive data that has variable length (max 50 bytes). I am using software NSS and my current approach is to start a DMA Rx/Tx transfer (using HAL_SPI_TransmitReceive_DMA) of the maximum expectable length when NSS goes down (in the corresponding GPIO callback) and to abort the transfer when NSS rises again (using HAL_SPI_Abort). From a functional perspective this approach works, but the abortion of the Transfer currently takes about 1.4 ms (at 8 MHz MSI Clock). As a result,  the answer to the Master is not ready when it clocks again.

Is there anything I can do better / different to improve the timing?

I know that using HAL_SPI_Receive_DMA instead of HAL_SPI_TransmitReceive_DMA for Rx would reduce the time required for aborting the transfer, but then it seems that I have no control over the data that is transmitted while receiving, which causes trouble on the Master side (which is outside of my control).

[Douglas MILLER]

This post has been escalated to the ST Online Support Team for additional assistance. We'll contact you directly.

[AMacd.1]

@Douglas MILLER

What is the outcome of your escalation?  I am having similar issues with a different MCU (STM32L451RE).  I need to be able to receive variable packets from the master.  As the OP is doing, I also use  HAL_SPI_Abort when NSS is raised by the master before the allocated DMA buffer is full.  The problem I have is that, after the abort has completed, a subsequent call to HAL_SPI_TransmitReceive_DMA fails ( HAL_SPI_ErrorCallback occurs and hspi3.ErrorCode == 0x20).

If you want, I have a narrowed-down CubeMX example project that demonstrates the issue.

Note: the master delays releasing NSS by 32us after the last clock to ensure the while loop catches the rising NSS well after the HAL has had time to call the completion callback function.

For me, this is a very serious problem.