Hello all,
We are bringing up DDR4 memory on a custom STM32MP257D-based SOM. We have made significant progress but are now blocked on a specific PHY training failure that we cannot diagnose without access to the Synopsys PHY firmware streaming message documentation. We would appreciate any help interpreting the failure and identifying the root cause.
Board Overview
- SoC: STM32MP257DAK3 (VFBGA424)
- DRAM: 2× Alliance AS4C512M16D4A-62BIN (DDR4-3200, 8 Gbit × 16, 1.2V, VPP 2.5V)
- Topology: 32-bit bus, 2 GB total, single rank, soldered down
- PMIC: STPMIC25APQR (I²C7)
- Reference HSE: 40 MHz crystal
- Tool chain: STM32CubeMX 6.16.1, STM32CubeIDE 2.0.0, STM32DDRFW-UTIL, STM32CubeProgrammer 2.22
Bring-up Status
We are using STM32DDRFW-UTIL with verbose PHY messaging enabled (hdtctrl = 0x05, custom g_waitfwdone.c patched to decode major messages and dump streaming messages).
Power Rails (all verified by HW measurement)
- VDD_DDR: 1.20 V :white_heavy_check_mark:
- VTT_DDR: 0.60 V :white_heavy_check_mark:
- VREF_DDR: 0.60 V :white_heavy_check_mark:
- VPP_DDR: 2.49 V :white_heavy_check_mark: (Note: ST BSP code uses 0x1E for LDO5 which produces 2.39 V; we changed to 0x20 to get 2.5 V per JEDEC spec)
- VDDA18DDR / V1V8: 1.80 V :white_heavy_check_mark:
Clock Configuration (matches STM32MP257F-DK reference)
- HSE → PLL2: FBDIV=30, FREFDIV=1, POSTDIV1=1, POSTDIV2=2
- PLL2 output = 600 MHz → MEMCLK = 1200 MHz (DDR4-2400 data rate)
Software Configuration
- STM32MP_DDR4_TYPE=1 in build
- DDR controller registers (DDRC, ADDRMAP, DRAMTMG, DFITMG, INIT) match the EV1 reference template, with the expected ADDRMAP7 difference accounting for our 8 Gbit chip density vs EV1's 16 Gbit
- All UIB/UIA/UIM PHY user input parameters match the EV1 reference values
- UIS_SWIZZLE values match the mainline stm32mp2xx-ddr4-2x16Gbits-2x16bits-1200MHz.h template
Initialization Sequence Progress (PHY firmware messages)
Step 0 (DDR_RESET) and Step 1 (DDR_CTRL_INIT_DONE) complete successfully. During Step 2 (DDR_PHY_INIT_DONE), the PHY firmware reports:
[PHY-MSG] 0x00 - end of CA training ✅
[PHY-MSG] 0x02 - end of read enable training ✅
[PHY-MSG] 0x01 - end of write leveling coarse delay ✅
[PHY-STREAM] header=0x00470002, len=2 (RxClkDly_Tg0, msg[0]=msg[1]=0)
[PHY-STREAM] header=0x04020000, len=0 ← failure
[PHY-MSG] 0xFF - TRAINING FAILED
We measured that DDR_RESETN goes high during step 3, confirming the PHY firmware is functional up to this point.
Key Observations
- We tested at both MEMCLK = 1200 MHz and MEMCLK = 800 MHz (via POSTDIV2=2 vs POSTDIV2=3 + regenerated config). The training fails at the identical point with identical error code at both frequencies. This appears to rule out signal integrity as the cause.
- CA training (msg 0x00), Read Enable training (msg 0x02), and Write Leveling coarse delay (msg 0x01) all complete successfully, suggesting the basic bus connectivity and clock/strobe alignment are good.
- The failure is in what appears to be the next training stage (DQS gate / Read DQ training).
- The PCB has a byte-lane swap on U7 (SoC byte 2 routes to U7 upper byte, byte 3 routes to U7 lower byte). Per ST community guidance, this should be transparent to DDR4 training, but we mention it for completeness.
- HW cannot perform continuity tests on DQ lines (all routed on internal PCB layers between BGA packages) and cannot scope the DDR clock (>600 MHz exceeds available equipment).
Questions:
- What is the meaning of PHY streaming message ID 0x0402 (header=0x04020000)? We'd like to see the Synopsys DDR5/4 PHY Training Firmware Application Note's decoding for this code to understand which sub-step of which training stage failed.
- What is the meaning of the streaming message header=0x00470002 with both data values = 0 that immediately precedes the failure? Is this an expected intermediate result or already an error indication?
- Are there known issues or required PHY parameter overrides for the STM32MP257D in the VFBGA424 package using DDR4 32-bit topology with 2× 8 Gbit chips at MEMCLK = 1200 MHz?
- Are there specific recommended values for any of the following parameters that we may not have set correctly?
- TRAIN2D (currently 0)
- HARDMACROVER (currently 3)
- DRAMBYTESWAP (currently 0 — though our PCB has byte swap on the second DRAM chip)
- Could the documented CubeMX 6.16.1 DDR_UIS_SWIZZLE reload bug affect DQ training behavior on DDR4, or is it strictly limited to the CA path (HwtSwizzle + DDR34_AC_SWIZZLE)?
I'm attaching full UART boot logs for MEMCLK=1200MHz and 800MHz, generated stm32mp25-mx.dtsi (for 1200MHz).
Regards,
Sergei
