Setting of GPIO PUPDR and OTYPER for SPI pins

[Gpeti]

Hello,

I know it sounds like a basic and dumb question but I actually didn't find the answer.

I have communication issues between 2 STM32H743 based Nucleos.

On the master I use SPI1.

If I use SPI1 on the Slave it works fine (repeated send/receive communications).

If I use SPI2 on the Slave, I have communication issues: the Slave receives data correctly but the Master receives crap (CRC error).

The settings are:

• for the master: GPIOs PA5,6,7 in Alternate Function, Very High Speed, PullDown set in PUPDR, OTYPER not modified (so push pull by default). SPI in simplex mode (I disable SPI between send and receive phase as described in errata sheet, prescaler to 8 (so should not be any issue of SPI clock frequency). All clocks are maximum as in code examples provided by STMicro (400Mhz fo Sysclock etc...)
• for the slave: exactly same config for SPI1 or SPI2 (I'm using pins PB13, PC2 and PB15 for GPIO, GPIOB and GPIOC have been clocked)

So my question: when using alternate function for a GPIO, does the pullup/pulldown setting matter ? Same question for output type (push-pull / open drain) ? And what settings should be used for SPI pins ? HAL examples from ST set all SPI pins with pull-down and push-pull. Is it correct ?

[Gpeti]

Sorry but didn't you say exactly the contrary ? "OTYPER push-pull; pulldowns mostly don't matter as the lines are supposed to be hard driven from the respective party whenever needed."

EDIT: I probably misunderstood the sentence, you probably meant: "set the pushpull and pullup/down don't matter"

[bivin mato]

For any port pin, first you need to decide which mode it operates. MODEy could be used for that purpose.

You could choose one of the below modes

• Digital input
• Digital output
• Alternate function
• Analog

Digital input mode

• PUPDRy is the only setting applicable for digital input mode. Other settings are don't care.

Digital output mode

• PUPDRy, OSPEEDy & OTy settings are applicable for digital output mode. Other settings are don't care.

Alternate function mode

• PUPDRy, OSPEEDy, OTy & AFRy settings are applicable for alternate function mode. Other settings are don't care.

Analog mode

• PUPDRy needs to be ensured 0. That's all. Other settings are don't care.

For your exact scenario, you would have to choose Alternate function mode for all the SPI relevant port pins. In that case for each of the SPI pin (MISO, MOSI, CS, CLK) below settings needs to ensured that it is right

PUPDRy, OSPEEDy, OTy & AFRy

Regards,

Bivin

[Gpeti]

I changed the OSPEED setting from "very high" to "high" and it seems to fix the issue. As far as I understood a higher GPIO speed creates more noise so it might explain my behaviour ?

[Gpeti]

Follow-up of this issue. I thought that the issue was only on SPI2 and that the speed of the pin had fixed it. But it happens that I have the same problem whatever speed is set and also on SPI1.

I also reduced the clocks because I noticed that the Nucleos were sometimes not able to switch to VOS1 range. Clock is now 200MHz for sysclk, 50MHz for APB and 12.5 for SPI clock (100MHz for spi_ker_clk and prescaler at 8).

The problem is always during communication from Slave to Master. Sometimes I receive only 0s.

The MISO pin at slave side is setup in push-pull. For the MISO pin at master side, I tried pulldown, pullup or none and I have the same behaviour. Someone suggested to add an extra pullup but I don't have any electronics parts to do so.

I recorded traces with a scope and I am not able to analyse them. I logged both SCK and MISO, once at slave side, once at master side. So the only difference between both traces is around 10cm of wires (obviously I tried several wires).

Output from Slave. You see that MISO (in yellow) is relatively clean and I checked that the bits are correct.

Input at Master side:

Do you understand the differences between the traces ?

Also what is strange is that the Master SPI interpretates this signal as only zeros (I've checked phase and polarity)

I'm really surprised because I have often worked with SPI on Nucleos and usually I didn't have any issue (at least at small frequencies and for short amount of data).

[TDK]

> I recorded traces with a scope and I am not able to analyse them. I logged both SCK and MISO, once at slave side, once at master side. So the only difference between both traces is around 10cm of wires (obviously I tried several wires).

The lower one clearly goes into hi-Z mode before SCK is done. If you're expecting the slave to be driving the signal at that time, it's not. Review the datasheet to see why.

This isn't a clock or pullup/down issue. The problem is the slave is not driving the line during the entire communication. Probably because it thinks it isn't supposed to, or is finished sending, or something.

[Gpeti]

But the trace recorded at slave side is showing a clean signal isn't it ? Isn't it strange ?

[TDK]

> But the trace recorded at slave side is showing a clean signal isn't it ? Isn't it strange ?

For the trace you recorded, yes. You're not saying these two are the same exact signal recorded simultaneously at different locations on the wire, are you? I would not believe that.

[Gpeti]

Simultaneously no. I hadn't enough probes to do so. However I recorded several times at each location on the wire and I had every time the exact same trace.

[Gpeti]

So I twisted every signal of SPI with a ground signal and it fixed my instabilities on SPI1.

However I still had issues on SPI2. I noticed that in the user manual of Nucleo 144 board , the functions of the pin PC2 that I was using for SPI2_MISO is only ADC, not SPI2_MISO. But in the datasheet of STM32H743ZI SPI2_MISO is indeed an altrenate function of pin PC2.

So I switched to SPI3 and now I don't have the issue anymore. To be honest I'm not sure yet whether it is just luck or if there si a subtelty of Nucleo pin mapping (for me I should be able to use all alternate functions of a pin that is accessible on the Nucleo ?)