STM32G473CETx: SPI Full Duplex Slave able to receive correct data but not respond

[STM-aspirant]

Hello everyone,

I have setup my stm32 to use interrupts and have enabled them to work on spi1 and all 4 i2c ports. The relevance of the i2c ports is that they run continuously and may call the interrupt service routine while the spi one is being called. To isolate this possibility I have disabled interrupts for the spi callback.

At the start of the main of the stm32 slave I call

HAL_SPI_TransmitReceive_IT(&hspi1, tx_buff, rx_buff, size);

From a Raspberry Pi I am sending from 0 to 95 in a single transaction while simultaneously reading the bus. The stm32 receives the data as expected (which I have checked in debug mode) but sends nothing in response. I have checked the miso port with a logic analyzer and you can see in the photos.

This is the SPI callback

#define BYTES_PER_BUS 	(8*3)
#define BYTES_I2C4		((6-2)*(3))
#define RPI_PACKET_LEN 	((8*3)+((2)*3))

uint8_t spi_rx_buffer[RPI_PACKET_LEN] = {};
uint8_t spi_tx_buffer[RPI_PACKET_LEN] = {};

void HAL_SPI_TxRxCpltCallback(SPI_HandleTypeDef *hspi)
{
  /* Prevent unused argument(s) compilation warning */
    __disable_irq();  
	UNUSED(hspi);
	flag_spi_transfered = true;
	__HAL_RCC_SPI1_FORCE_RESET();
	__HAL_RCC_SPI1_RELEASE_RESET();
	MX_SPI1_Init();

	int nb_arrays = sizeof(sensor_arrays)/sizeof(sensor_arrays[0]);
	for(int i=0; i<nb_arrays;i++){
		uint8_t buff_size = (i == 3) ? BYTES_I2C4 : BYTES_PER_BUS; // account for less sensors on i2c4
		memmove((tx_buff+(PREAMBLE_LEN)+(i)*(BYTES_PER_BUS)), sensor_arrays[i]->getResultBuffer(), buff_size);
	}
	HAL_SPI_TransmitReceive_IT(&hspi1, tx_buff, rx_buff, RPI_PACKET_LEN); // send all data to RPi
	__enable_irq();   // Disable all interrupts globally
}

I reset the port every time because I have seen that problems may be linked to desynchronization between master and slave.

I'm quite unsure of what I am doing wrong, does anyone have any idea? Could it just be a damaged chip or am I missing something? Is static discharge a feasible culprit?

Thanks

P.S. I checked the SPI_FLAG_TXE at the start of the callback and literally the next line after calling HAL_SPI_TransmitReceive_IT and both times it was 1. Is this normal? The raspberry pi is sending every 2s only so there is no way it could complete a new transaction immediately after.

[waclawek.jan]

Write a simple program with polled implementation of Tx only.

This can be pulled out very simply by direct register accesses - initialize the SPI-related pins in GPIO, set up SPI for slave, and then in a loop check the TXE status bit and if set, write some (nonzero) byte into the (transmit) data register.

JW

[STM-aspirant]

With this code as the whole main I still got no response. It prints "Writing" twice before the master even sends anything but I don't see anything on the logic analyzer. alt_main() is called just before the while(1) in the normal main()

uint8_t spi_tx_buffer[RPI_PACKET_LEN] = {0x44};

void alt_main(){	

	while (1)
	{
		if (__HAL_SPI_GET_FLAG(&hspi1, SPI_FLAG_TXE)) {
		    
			uart_printf("Writing\n");
		    hspi1.Instance->DR = spi_tx_buffer[tx_index];  

		    tx_index++;  
			if(tx_index >= RPI_PACKET_LEN)
				tx_index = 0;
		}

	}
}

[waclawek.jan]

Read out and check the SPI registers content and relevant GPIO registers content, especially for MISO.

Check, that MISO is properly connected to your LA probe by setting it as GPIO Out and toggling.

JW