Bytes being transmitted on MISO when calling HAL_SPI_Receive_DMA() in slave mode

[RBack.1]

I am using the STM32F746VET6 and the HAL packaged with v6.5.0 of STM32CubeMX. It is operating as a slave with a Raspberry Pi as a master. When inspecting my SPI communication I was surprised to sometimes see bytes being transmitted on MISO when HAL_SPI_Receive_DMA() was being called. I *usually* don't see anything being transmitted, but sometimes I do and it's the same byte repeated over and over again. It doesn't seem that the MISO behavior when calling HAL_SPI_Receive_DMA() is specified for the HAL, but I'd expect the line to be low when receiving only.

[waclawek.jan]

This is the normal behaviour of SPI, it repeats the last transmitted frame. If you don't want to see that, either transmit zeros explicitly (at least once - it will be repeated as I've just said), or switch the MISO pin to Output in GPIO and set it low.

​

Cube/HAL won't help, but that 's how Cube/HAL works: it's good only for the "usual cases" which can be easily clicked in CubeMX.

​

JW​

[RBack.1]

Huh...I'm actually *more* confused then, as I *usually* see the MISO line low when receiving. Since my last transmission is always ended with a 16bit CRC, it'd be strange for my last byte to typically be 0x00. It's only for 3 or 4 commands where MISO transmits a value when I receive my next command.

This actually doesn't result in any undesirable behavior in my system, but I hate leaving things unexplained. That sort of thing tends to bite me if I ever try to change the system later.

[S.Ma]

Fully understand, worth noting it. So many time the short term lazyness cost much more later on as maintenance cost.

If your spi is in 4 wire mode, as slave, bit in and out are forced by master clock. What was last wrote on the data register maybe repeated. Please note that if you use spi with fifos and dma cyclic mode, the tx fifo remains filled when master stop the clock, and fifo old content will be going out at next master data exchange. Resetting the fifo is tricky and unintuitive for some parts.

[RBack.1]

> Resetting the fifo is tricky and unintuitive for some parts.

This seems to be true. Having the extra layer of the HAL complicates things too as I don't really know what it's doing. It's weird to see inconsistent behavior, however. Usually I get 0x00 on MISO when I receive, but for 3 or 4 commands it is not 0x00.

[waclawek.jan]

Maybe it's the FIFO, maybe disabling/enabling SPI.

JW

[RBack.1]

I can try that. Thanks!

[S.Ma]

Check which SPI version you have. In mine had to to a syscfg reset of SPI to flush fifos, disable did not affect fifod. Result may vary.. Thr SPI fifo time optimisation came with a time setback....

[RBack.1]

Honestly, do you know where I look to check that? I looked through the file headers before writing this post and ended up just saying the MX version as I couldn't find a revision number in the autogenerated files.