STM32 SPI pin mapping change on the fly

[Siwastaja]

I have an application where SPI access noise is considered possibly problematic by the SPI slave device manufacturer and hence, to guarantee analog performance, separate SPI bus per device is recommended (i.e., not sharing the bus). Time-wise, multiplexing wouldn't be an issue. I'm running out of the SPI peripherals and want to avoid adding external bus isolation switches because this is area restrained as well. Also right now don't want to add any excess parts in BOM for reasons we all know too well.

It occurred to me that I could just connect the sensors to different pins of the same SPI peripheral. Then just change the Alternative Function registers before each access, to disconnect the SPI slave from the "old" pins and reconnect it to different sets of pins. Turn on the internal pull-up on nCS for both relevant pins, of course, and hope the SPI peripheral doesn't throw a tantrum. Well, having to reset it through RCC registers wouldn't be a disaster, so really, would you agree this is the worst case that can happen?

I see no reason why it shouldn't work, but knowing how delicate snowflakes STM32's SPI implementations are, need to ask: has anyone actually tried this?

I use hardware nSS control (because, surprisingly, I was able to get this work in this case, go figure!)

STM32H750 if that matters (well of course it does because SPI peripherals are all different; but if you have had success with STM32F3 for example, that would still be an interesting datapoint).

The SPI slave ICs are prototypes, not public and not discussable but surprisingly implement normal SPI with no oddities.

[Jeroen3]

Yeah I think that should work. The peripherals using gpio multiplexers are unaware of anything downstream their outputs.
You also manually have to configure the GPIO in the right mode anyways.

It's actually a common beginners mistake to setup peripherals without the GPIO alternate function and it not working.

I suspect, but I've never tried it, that you can make the same SPI appear on more than one GPIO port at the same time. I'm sure this is out of spec, but it would be interesting to try.

I do this alternate function change for I2C on an F4 to perform a bus reset, because apparently that's something i2c needs sometimes and the i2c peripheral can't do that.

Caution though, not all chip families use the same architecture when it comes to alternate functions and remapping. It may not work properly on an F1 for example.
But I suspect it will work fine on newer chips.

I do think the input lines may give a little glitch, but since your spi master this shouldn't be a problem. You can always do a dummy transaction.

--

An alternative hardware method for SPI would to gate them using some simple logic gates on chip select. Like what's inside them, but then externally.

[SiliconWizard]

I've never used the STM32H7 series, but on the 4 series, that approach works. I don't see a reason why it would not. The I/O multiplexer doesn't have any influence on the peripheral themselves AFAIK.
Now I can understand your questioning on that because neither the DS nor the RM are particularly detailed on the I/O multiplexer itself and how writing to the corresponding registers might have an effect on peripherals, such as possibly resetting them. I haven't seen that behavior happen on the 4 series again (L4/F4), but no experience so far with the H7.

In any case, to make the switch glitchless, you should arrange to configure the pins so that when they are configured as GPIO (not the alternate function), they are in the same state as what they will be when you switch to the alternate function - will matter for the clock and CS, you can ignore that for the data pins of course.

[Siwastaja]

Yes, I agree with all above. Just wanted to hear any comments because STM32 tends to sometimes show some totally unexpected surprises and this happens to be quite tedious to hand prototype, so need to go for PCB directly which would be nice to get working on the first try.

For example, on STM32F334, I found a silicon bug (undocumented in errata; ST did never respond to tickets) where enabling a DAC, connecting the output internally to a comparator, without connecting it to an output pin, breaks the pin which would be its output pin (prevents using it for GPIO); yet it doesn't drive it either, just makes the pin nonfunctional! Resulted in a board respin. Same chip has "output inversion" bit in comparator, but setting that bit does not invert the output of said comparator (as it goes to other peripherals), expect in status register which makes debugging the thing confusing.

But analog routing is kind of special case anyway. The chances of this happening with simple digital peripherals is smaller. I expect those go through simple digital muxes controlled by AF bits. ... but you never know.

[SiliconWizard]

While there shouldn't be any bad surprise as we said, I'd still give it a try before settling on a solution (or even worse, before designing a PCB.) Do you have any dev board you can try this on?

[Siwastaja]

Oh, if it doesn't somehow work then the solution is to populate only some sensors (one per SPI bus) and sync the data outside of the boxes (after CAN bus), so it's not a disaster. That was the original plan that was presented to me anyway, I just saw an opportunity for some time/cost savings / simplification.

Thanks.

[julian1]

For stm3204, I have a design that flips the AF pin mapping between two different cs/nss pins (spi1 pa4/pa15) for the same spi port.

This is done on the fly, to control different spi peripherals with hardware cs/nss. For my case, the clk, mosi, miso pinouts are shared and not swapped. The unused CS is reconfigured as a high-Z input, but I also have an external pullup. 

[Siwastaja]

Just to come back on this, changing the pin mappings (one set of pins to GPIO, other set to AF; and vice versa) worked exactly as expected, no problems. The code turns the SPI peripheral off during the swap (CR1 = 0). No need to reset through RCC reset registers. No board respin necessary for this or other reasons.