OCTO SPI output impedance on H7-series

[Southbranch]

I have swapped from a custom PCB-board with a 6-layer stack using a STM32H725IGKB, to another custom board with a 4-layer stack using STM32H723ZGT6 (simpler package).

I am using an external OCTO SPI on both boards, but I have R/W errors with the 4-layer board.

Both boards are routed with 50 ohms impedance and uses 33 ohms series resistors for the OCTO SPI.

I am wondering if the output impedance is the same for these two H7-devices?

[Southbranch]

Oh.. I have not heard of this and there was no warning in CubeMX during configuration...

Obviously I can't change it with less then making a new PCB-design.

Did you missed your last sentence "try with.." ?

[AScha.3]

Right, i edit...

+ was same for me , but i was using SPI -> TFT on H743 , so just changed to use other SPI for this.

But i was somewhat ...disappointed , this "analog only or low speed/power pins" should get a clear and eye-catching warning , > do not use for output any hi-speed signals <   or so.

[Southbranch]

Thanks,

@st, could you please provide a comment on this (impedance + PC2/PC3 pins) before I start re-design my PCB?

[AScha.3]

Hi,

Just looking at ds, pin list, at pins PC2+3 :

If "standard" pin, standard timing - as expected.

If something other, like _a -- other timing, need look at details for this kind of pin.

[Southbranch]

Thank again,

Could you please elaborate a bit.

I have checked RM0468 but I can’t find anything explicitly stating that PC2_C/PC3_C could not be used for high speed communication.

[LCE]

Check the datasheet not the RM, search for "PC2".

Datasheet of H733, should be the same for H723/H725.

See note 4.

Even worse, see again note 4 for HyperBus, max freq with PC2 is 47 MHz:

Dear ST, this should not be in smallest print in some footnotes, but bold and BIG in each mentioning of every use outside of analog input.

There was no CubeMX warning?

[Southbranch]

Many thanks LCE for providing this info.

Please ST, perhaps you could also comment on this before I start re-route my PCB-traces?

[BarryWhit]

@Southbranch see previous threads on this. For example:

https://community.st.com/t5/stm32-mcus-products/stm32h735v-lqfp100-pc2-c-and-pc3-c-speed/td-p/214053

[tjaekel]

My five cents:
A GPIO output on MCU is for sure below 50 Ohms. But which exact value might depend on your drive strength settings. Also: using a "shared pin" like PC2_C (which has also an analog path inside MCU and an analog mux involved) might make it unpredictable about the "impedance". I would try to avoid using "muxed" signals (having an analog ALT feature in parallel, even not used but a circuit inside chip).

It is not just impedance: if you change your PCB from 6 to 4 layers: I would also consider these:

1. have all the traces the same length? (length compensation, esp. if clock signal is shorter as data signals)
2. is there enough ground shielding ("ground pour")?
3. Could you have "cross talk" between QSPI signals (esp. clock and data signals) or "cross talk" from another high speed signal (e.g. an USB signal crossing or going along with QSPI signals, or signals going for a length in parallel with each other, with reduced clearance or missing ground separation)?
4. Is there "noise" on the power rail? Decoupling not strong enough? Power traces too long, thin and in
   "sequence"? (not a real grid)
5. backward current via GND is "noisy" (e.g. GND flow too long, blocked by other components on board)?
   (often we forget to check the ground current current flow - same short paths on GND as on PWR)

• Do you have a scope screenshot for signals doing QSPI access?
  (when do you see errors? - scope screenshot)
• Did you do an "eye diagram" (with scope)?
• is it working if you lower the QSPI clock speed?
• have you tried to use the DLYB features? (and calibrating the timing)

BTW: 33R series termination is pretty common. But the rule is: such a 33R resistor should sit close to the driver output. But if you do a read: the 33R might sit on the "wrong end" (close to MCU, not on QSPI "outputs" during a read). So, these 33R are just a compromise. I would rather check for cross-talk, power rails, GND return flow and deblocking issue.

[Southbranch]

Thanks for pointing me to previous threads,

The first was from 2021 but was indeed covering the PC_2/PC_3 issues. Now, it seems the fastest action to get onwards would be for me to re-route traces with other GPIOs to rule out this potential cause.