cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7 SPI Slave Dynamic Message Length

ChrisShaw
Associate II

Hi,

I'm using SPI to communicate between two micros - one F103 (master) and one H750 (slave). The data communicated will be vastly different in purpose and size (e.g. from simple requests to firmware image download) and so the designed protocol necessitates a dynamic message length. The idea is to have the length early on in the message, and the destination micro reads the first few bytes of data to determine how much it should read. We use something similar on another micro (L4 series) and it works well. We use HAL_SPI_Receive_IT() to request 4 bytes, then determine the actual length and call the function again to receive the entire message.

This does not work on the H7. Requesting 4 bytes is fine, but at the EOT interrupt handler in the HAL the peripheral is disabled (call to SPI_CloseTransfer) before calling the HAL_SPI_RxCpltCallback(). So when I request reading the remainder of the message, the data is corrupt. I think the peripheral re-enables but the data is then read in as it arrives; this may be mid-byte hence the data is corrupt - not missing bytes.

Reading the H7 SPI user manual it mentions that “Write to the SPI_CR2 register to select length of the transfer, if it is not known TSIZE has to be programmed to zero.” This makes sense I guess, and you run off the RXP events to read data. But the API does not allow you to do this - there is a check for the reqested data amount not being zero.

I can't see an easy way to use the API for my purposes - unless I'm missing something. At this point I can only see that I need to either ditch the SPI HAL implementation, or make changes to it to allow using TSIZE of zero and calling HAL_SPI_RxCpltCallback() from the RXP event. 

Does anyone have any better suggestions or can point out my error?

2 REPLIES 2
Piranha
Chief II

I can't see an easy way to use the API for my purposes - unless I'm missing something.

Does anyone have any better suggestions or can point out my error?


It seems that for your protocol all messages have to have the same constant sized header type, preferably with a checksum on header, and some timeout mechanism, which re-synchronizes the communication in case something goes wrong.

ChrisShaw
Associate II

For anyone requiring an answer to this in the future, the solution was to use the low-level driver instead and write my own implementation of the HAL.