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

Senior

Question

Setting of GPIO PUPDR and OTYPER for SPI pins

Forum|Forum|6 years ago
May 12, 2020
18 replies
5900 views

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 ?

This topic has been closed for replies.

waclawek.jan

Super User

The single most important thing is to have short interconnections (that includes paths on the PCB, 10cm may be too long, stubs on the PCB going to some different onboard chip may have impact), good ground/return, best is individual return for each signal and signal wires twisted with their respective return.The most important is to maintain SCK integrity. VeryHigh OSPEEDR may be surprisingly wrong, try lower. You may need to add series terminator resistors to impedance-match.

If you switch off SPI between transactions, make sure slave is deselected the whole time (NSS is high).

OTYPER push-pull; pulldowns mostly don't matter as the lines are supposed to be hard driven from the respective party whenever needed.

JW

GpetiAuthor

Senior

Thank you, I didn't know for high speed being wrong. Will give it a try. I don't use NSS at all

TDK

SPI1 and SPI2 are on different APBs, which typically have different clocks. Your slave SPI clock should be higher than the master clock by 2x. Lower the master clock or increase the slave clock and try it. Could also be the slave doesn't push data out fast enough for the master. A logic analyzer would provide more insight.

"If you feel a post has answered your question, please click ""Accept as Solution""."

GpetiAuthor

Senior

yes sure, slave processing speed is definitely an issue, i am taking it into account. Unfortunately I don't have a logic analyser but agree with our comment.

Why did you strike through the first sentence ? Is it wrong ? (didn't have time to check yet)

waclawek.jan

Super User

> A logic analyzer would provide more insight.

+1

bivin mato

Associate III

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 ?

Find the settings applicability below.

GpetiAuthor

Senior

Sorry I don't understand the meaning of this figure.

bivin mato

Associate III

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

waclawek.jan

Super User

> when using alternate function for a GPIO, does the pullup/pulldown setting matter ?

Yes.

> Same question for output type (push-pull / open drain) ?

Yes.

> And what settings should be used for SPI pins ?

Whichever fits your application. With SPI, it would be typically push-pull, no pullup/pulldown; but then there are also non-typical applications.

JW

GpetiAuthor

Senior

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"

GpetiAuthor

Senior

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.

"If you feel a post has answered your question, please click ""Accept as Solution""."

GpetiAuthor

Senior

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.

"If you feel a post has answered your question, please click ""Accept as Solution""."

GpetiAuthor

Senior

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.

GpetiAuthor

Senior

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 ?)

Sign up

Login with SSO

Login to the community

Login with SSO