STMH7 SPIv3 - MISO in slave mode

[Sparky]

Hello ChibiOS fans

I am using SPIv3 driver on STM32H7 with the usual tweak in [font=Courier New]hal_spi_lld.c[/font] to allow STM to function as in SLAVE role. Generally there is no issue with communication to the MASTER (as both parties are configured for the same number of bytes in the SPI transaction), however in terms of SPI signaling it looks a little incorrect.

The image below shows STM driving MISO (yellow) low and then immediately released after the last byte is clocked. (DMA is used for the SPI transactions.)

The SPI MASTER continues to assert slave select (NSS, blue) low for a long while after the last CLK (pink). I think would be better if STM drive the MISO line until NSS is de-asserted...after all, it is being addressed by the MASTER during this time.

Just wondering if other people observe the same MISO behavior with their SPI SLAVE implementations and thoughts on resolution.

Thank you!

[Giovanni]

Perhaps it needs a pull-down.

Giovanni

[Jacon]

Or change NSS driving pin output mode to push-pull...

[rew]

When there is no more data to be sent, what value (0 or 1) would you want to see? With there being a "protocol breakdown" the master should expect to receive garbage. Or at least discard the data that it gets.

So the behaviour of the chibios+chip is maybe unexpected, but is it wrong? Does it cause problems for you'? If you enable pullup or pulldown as giovanni suggests on one or both of master/slave, you'll see much quicker convergence to a defined level. But does that help you in a way?

If your master doesn't know if your slave has 100 or 150 bytes, but the first few bytes will tell it, you can just transfer 150 bytes and once the transaction is complete ignore the last 50 bytes or not. That's probably much easier to implement than to arrange for an interrupt once enough bytes to know the actual length are transferred and then adjusting the DMA size.... Ongoing DMA? Hmm. not going to happen, if I remember the DMA controller specs correctly...

I do agree that most hardware-implementations simply tie the output-enable of the MISO line to the chip select line. So it is different here, but does that difference matter to you? Why?