Portenta H7: SPI SW NSS mode

More for experts and general issue with STM32H7 MCU:
Using SW NSS SPI - be careful

Realized (experience):
You can configure SPI with a SW NSS pin (the NSS signal is driven by SW, as a regular GPIO out pin). This is in comparison with HW mode where the NSS signal is generated when you kick off a SPI transaction.

In general fine, but it has some implications (and SPI can fail):

The SPI signals are FLOATING when not any transaction takes place.
SPI in DMA mode (I use) generates the SPI signals when DMA was enabled (deep inside HAL driver).
So, you can set the NSS signal way before SPI DMA is enabled. But all the signals on SPI, esp. SCLK, are still floating for a while.
Also the NSS signal - in HW NSS mode - is floating! : you might need a pull-up to avoid this
floating signal (otherwise it select an external slave device but no other signals are valid).

The "problem" with a floating SCLK signal is this:
Let's assume you have a pull-up on SCLK, it ties the floating SCLK high.
But you want to use SPI in SPI Mode 0: this means: the default (calm) signal level is low.
But due to fact that SCLK is floating when SPI is not activated - the SCLK will give you edges due to the pull-up. This can make the SPI communication to fail (two wrong clock cycles on SCLK).

It is very tricky to find when to drive the NSS signal in SW mode:
When using SPI in DMA mode - you are potentially too early with NSS and even too late,
e.g. NSS is active already before DMA SPI will enable all the other signals, still floating when NSS
is already active.
The same for de-asserting NSS in SW mode (toggle the GPIO to "high" mode): the DMA has finished,
the signals are already floating but NSS de-asserted comes too late.

The only solution I have found (and STM does not have HAL drivers to make it better):
place the GPIO toggle instruction deep into the HAL drivers, e.g. AFTER you have enabled the DMA,
or de-assert immediately when the DMA complete callback kicks on, actually the interrupt for this DMA/SPI event.

Doing this GPIO handling "outside" the HAL drivers fails!
So, you had to modify the HAL drivers, deep inside (and you risk the potential to update STM HAL drivers anytime later with a newer version).

Conclusion
even HAL drivers support and allow to use SW NSS mode (I need, e.g. to generate a SPI transaction larger as 64KB - not possible via the drivers) - you have to be careful when do you generate the NSS signal via SW: potentially - you are too early (when activating NSS as low) and even too late (to de-assert to high when all done): SPI signals become floating for a short period
of time and the external chip can see wrong signal transitions (e.g. unintended clock pulses on SCLK).

I guess: it is mainly an issue when using SPI in DMA mode with SW NSS. Potentially, in SW polling mode - it is fine.

Just to bear in mind:
MCU SPI signals become floating when no SPI is in progress. At least a pull-up on NSS signal might be needed. And a pull-up vs. pull-down should be aligned with the SPI Mode you want to use.

So,
bear in mind:

  1. MCU SPI signals become floating when the SPI device is not used.
  2. When using a SW NSS signal: this can be active before the SPI device "stops" with floating signals (drives the other signals much later or even let it float again when NSS is still active)
  3. floating signal can generate a "false" pulse (esp. on SCLK) seen by external chip and generating a wrong SPI command
  4. if and how to use pull-ups vs. pull-downs depends on the SPI mode you want to use
    (these pull-resistors should act on the "inactive" (calm) signal level)
  5. a pull-up on NSS is always a good idea, but a pull-up on SCLK can be wrong (might need to be a pull-down - verify with the SPI Mode to use)