I am using STM32H7 HAL_SPI_transmitreceive_DMA, where are all internal buffers and how to refresh data?

[pflunzi]

Hi,

I am using an STM32H753 connected to a raspberry PI via SPI. The STM32 is connected as slave. With CubeMX I configured the STM32 to be an SPI Slave with both DMAs configured as circular. I am having a struct with live data (refreshed every 10ms) and the raspberry can ask anytime for the data. For this, I am starting TM32H7 HAL_SPI_transmitreceive_DMA before the main loop. After placing the struct with live data into the D2-Memory, I could get correct data via DMA on the raspberry.

Unfortunately it seems that there is a buffer anywhere, which buffers a part of the struct. So when I stop requesting data from the STM32 and ask after 5 minutes again, the first data I get is 5 minutes old.

Is there a way to trigger a refresh of the data for SPI? I tried different things, like taking only software NSS, use the CS-Pin as interrupt source and then start a HAL_SPI_transmitreceive_IT or HAL_SPI_transmitreceive_DMA with non-circular buffer and then clear the SPI_CR1_SSI Bit in CR1 register, but it seems to slow, so that I only get corrupted data.

Can somebody tell me the fastest way to refresh the buffered data (I actually don't know whether it is an SPI or an DMA buffer problem)? I don't refresh the data when the CS-Pin is low, so there should always be valid data and I don't need any buffers at all.

edit: The old data ist still in Buffer when I do not use the DMA, so I would guess it is something SPI related.

[Bubbles]

Hi @pflunzi​,

yes, there's a FIFO integrated in the SPI peripheral. It's described in the reference manual, you can anytime test how much data is in the FIFO. Procedure to empty the FIFO is also described there.

BR,

J

[pflunzi]

Hi,

if I am watching the TXBuffer, there actually is the correct value inside and it changes with time. The first value I got was another than I could see in the buffer (it was the old one from the last time I used SPI)

I also use the CS pin as an interrupt source ,and also tried this (I think this is the part you are referring to)

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
	if (HAL_GPIO_ReadPin(PI_CS0_GPIO_Port, PI_CS0_Pin) == GPIO_PIN_RESET)
	{
		__HAL_SPI_ENABLE(&hspi1);
	}
	else
	{
		__HAL_SPI_DISABLE(&hspi1);
		//SET_BIT(hspi1.Instance->CR1, SPI_CR1_SSI);
	}
}

[Bubbles]

No, I don't think we're on the same page. You are referring to SW, while the FIFO is HW. Chapter 50 in the part manual describes the SPI HW behavior, including the FIFO. Here:

STM32H742, STM32H743/753 and STM32H750 Value line advanced Arm®-based 32-bit MCUs - Reference manual

The SPI is designed to transfer whole messages. The unorthodox approach you choose means that the DMA will prepare data in the FIFO even if the raspberry is not going to read it immediately. But the data (2 bytes I believe) stays inside the SPI buffer.

Jarda

[pflunzi]

Hi, I read the part, that is why I am disabling and enabling the SPI. I am using the HAL_macro __HAL_SPI_ENABLE(&hspi1), but it is the same as setting and resetting the SPE bit.

During the transfer I am transferring 84 Byte, the temperature I am referring to is a float and it is located on Byte 4-7, so the 2 byte buffer you are writing about could not really have an effect, even if it is not flushed with the SPE bit.

You said it is an unorthodox approach, I am willing to change to any other approach, but actually I cannot think of any other approach, since as slave you never know when the master asks you something, so I can only think of having latest data available.

[pflunzi]

Some additional information.

I tried to following to make sure it is a problem I am having with the microcontroller and not the raspberry.

I heated the element a bit, so that it cools down to have a decreasing temperature. The values I get have a noise in the range of 10mK, so two consecutive measurements only differ by 0.01.

I took two measurements to make sure I got the real temperature. Then I waited ~30s and resetted the microcontroller. After additional ~30s I read the temperature two times. The first temperature I got was between the first one and the last one. This somehow prooves that I got the value from when the micocontroller was resetted.