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]

Many thanks tjaekel,

I believe I have reasonable “precautions steps” into consideration.

• All traces are length matched more or less exactly with a minimum of vias.
• No other signals in that area of the PCB.
• Power decoupling seems fine.
• I have a relatively simple scope measuring max 100 MHz but I have checked all signals one-by-one during a R/W-loop for low speed. Signals looks ok even though having some ringing, but not more than my working 6-layer board.
• For lower speeds, I can read configuration register and IDs but as soon as I switch over in memory mapped mode and start do R/W-tests there are R/W errors.

Otherwise I think I have tested everything accept for the DLYB

I am uncertain on how to measure cross-over or GND noise, do you have any tip?

[LCE]

Memory-mapped mode doesn't even work with a clock rate of 20 MHz (or anything else below the 47 MHz mentioned in the datasheet) ?

The ringing you see on the scope might come from your scope measurement itself, always use a spring tip for GND, not the usual 10cm or so GND clip.

[Southbranch]

Memory mapped mode works fine with OCTO SPI freq. set to 166 MHz (max for the chip) on the 6-layer board.

On the 4-layer board R/W does not seem to work even how low I set the freq.

[AScha.3]

Try at very low speed, 4 or even 1 MHz, to prove your design, but check with scope, the _C pins still working at all ( as I said, I killed one just by using at 16 Mbit - then it never worked again ! ). So maybe you already have a dead pin, then cannot use it to prove the design.

[Southbranch]

Thank you all for contributing with good ideas and advices, highly appreciated :smiling_face_with_smiling_eyes:

I'll park this thread now and will go ahead with a new PCB-design without using PC2_C/PC3_C.

[Southbranch]

Problem solved!

It turned out to be the PC2_C/PC3_C pins that caused the faulty communication. I just received a new PCB-version of our custom board and it all works fine now using another pin assignments.

Many, many thanks for pointing this out :grinning_face: