unexpected GPIO behavior

[LBaum.3]

Hi ST community,

I am interrested in using the STM32F767-Nucleo board for SPI communication. My system is as follows. I have one STM32F767-Nucleo board which is my SPI slave and a Raspberry Pi which acts as SPI master device. The Raspi should read data via SPI from the Nucleo board. There is also one wire which is used from the Nucleo board to tell the Raspi when data is ready to be read. So every time data is ready the STM32 toggles this GPIO pin and the Raspi gets an interrupt and forces a read command.

Now my problem is not the SPI communication, no this works very well. The problem is the GPIO pin which forces interrupts at the Raspi and after that SPI read commands for the STM32. After some time of working properly the GPIO pin does nothing for about 400ms to 500ms and I don't know why this happens (see picture GPIO_stop_working.png) .

I use the DMA to transfer data from the memory to the SPI peripheral. If timer 3 generates an Interrupt (this happens every 100ms) HAL_TIM_PeriodElapsedCallback will be called. In the callback function I toggle GPIO pin PG2 which is the wire that tells the Raspi data are ready to be read. If the first timer interrupt occurs the STM32 will send only one number and after that at every timer interrupt data gets sent with HAL_SPI_Transmit_DMA.

My first idea was maybe the Raspi causes this discrepancy at GPIO PG2 but I replaced it with antother STM32F767-Nucleo board which has the same task as the Raspi and the same problem occurs. Therefore I think the problem is at the side of the Nucleo board and not the Raspi.

ps: The code from the STM32 is in the first reply of this post.

-Lukas

[LBaum.3]

In the mean time I lookt at the interrupt priorities. There are three DMA global interrupts which have the same priority as TIM3 global interrupt. I set the DMA interrupts at a lower priority and size that I haven't seen the glitch periods any more. I tested three times for 60s each and now it seems to work well.

But now I encountered an other problem. Some time after sending the MISO line remains high instead of low.

[LBaum.3]

I also encountered that the whole package before MISO remains high contains the same number. It is always the sencond last value from the package before. (In this case 2005)

[TDK]

Sounds like it was stuck in another interrupt somewhere. Glad you got it sorted.

> Some time after sending the MISO line remains high instead of low.

MISO staying high is not a problem. It does not violate any protocol or convention. It probably keeps the value of the last bit sent, or the next bit to send, although neither is a requirement. The only requirement is that the signal is valid on the clock edge where it is sampled.

And if the transfer is done, then the value of MISO is "don't care".

[LBaum.3]

Yes I think so.

Ok, that's fine. Then there is just one problem. Sometimes the whole data package contain the same value.

Do you have any idea what's the reason for this?

[TDK]

Perhaps the call to HAL_SPI_Transmit_DMA fails due to it already being busy. You should monitor the return value to detect errors.

[LBaum.3]

I monitored the return value of the HAL_SPI_Trasmit_DMA function as you said and you are right. The return value is sometimes busy. More precisely after each faulty package the retuned value is HAL_BUSY. That's a problem because the faulty package gets sent and afterwards I can determine if the package was correct or not according to the return value.

[LBaum.3]

Sorry there was an error at monitoring the return value.

The function returns the HAL_BUSY status before the faulty package comes.

This occurs rarely, for example 2 times within 530 sent packages. Do you have a explanation why this happens?