Delay issues on HAL_SPI libraries

[vicfer89]

Hello everyone, 

 

I am using SPI to communicate two Nucleo Boards (a NUCLEO-L432KC and a NUCLEO-F411RE one), and i found out a weird behavior. The idea was to perform a transaction Master -> Slave in order to select a "register" to read. Once the Slave has received the "register", the Master request the information and the Slave shall send the information to the master.

 

In order to perform this, interruptios were used in the slave side. The "register" logic is still not present, but the concept is the aforementioned one.

The Master code is as follows (only SPI-Related lines):

 

HAL_SPI_Transmit(&hspi2, txbuff, 2, 1000);
HAL_Delay(1); /* DELAY BETWEEN TRANSACTIONS */
HAL_SPI_Receive(&hspi2, rxbuff, 12, 1000);

 

And for the slave, following code is used:

 

/* USER CODE BEGIN 2 */
HAL_SPI_Receive_IT(&hspi1, buffreg, BUFFREG);
/* USER CODE END 2 */

 

SPI Interruption handlers are as follows:

 

void HAL_SPI_RxCpltCallback(SPI_HandleTypeDef *hspi)
{
	HAL_SPI_Transmit_IT(&hspi1, buffdat, BUFFDAT);
	rxData++;
}

void HAL_SPI_TxCpltCallback(SPI_HandleTypeDef *hspi)
{
	HAL_SPI_Receive_IT(&hspi1, buffreg, BUFFREG);
	txData++;
}

 

When the delay (HAL_Delay(1)) in the first pice of code (MASTER code) is not present, the communications cannot be performed properly, and weird values are read in the reception. But when it is pressent, the program works properly.

Are there any way to overcome this delay?

Is there another better approach to do so?

Thanks in advance.

[vicfer89]

New update... 

Performing some tests about the delay, I need to wait at leats 55 clock cycles in the master to start the communication and receive data:

 HAL_SPI_Transmit(&hspi2, txbuff, 2, 1000);
 //HAL_Delay(1); // OLD APPROACH
 for(int i = 0; i < 55; i++) // MINIMUM WAIT
 {
	 asm("NOP");
 }
 HAL_SPI_Receive(&hspi2, rxbuff, 12, 1000);

 

[Bob S]

Of course you need to give the slave time to process the first packet and get ready to transmit the response.  If the master starts the read before the slave is ready, you will receive garbage.  And that delay may change depending on interrupt priorities and how heavily loaded (busy) the slave MCU is.

[vicfer89]

Hi @Bob S,

Thank you so much for your response. This was what i figured out and the reason behing the blocking delay between transactions. 

I've been reviewing the examples and applications at STM32 Firmware libraries and the solution there is to perform a "synchronization" between master and slave in order to determine whether both are synchronized or not, but I don't know if there is a better solution.

In my case, the key is to "play" with the libraries, so I am trying to optimize it as maximum as possible to get the fastest reponse, so if you know a better solution or some kind of "ACK" (despite of the aforementioned one seen at the STM32 examples) i ill apreciate you to share.

Best regards,

Víctor.