Cannot access LPDDR3 memory from a STM32MP153AABxx

[qyx]

Hi,

on a custom board with a STM32MP153AABxx and a W63AH6NBV 1Gbit LPDDR3 memory I am failing to initialise the DDR properly. I made the required changes to the upstream u-boot device tree files, added support for UART8 debug console and some minor things and compiled the SPL. I enabled the DDR interactive console and loaded SPL to the MPU using STM32 cube programmer CLI. STPMIC1 is properly configured, 1V2 and 1V8 DDR power rails are present. So far, so good. Trying DDR tests one-by-one, all are failing.

LPDDR3 is wired according to AN5031 (Rev 4), section 10.1.7. I tried ODT both grounded and connected to the MPU. Routing should be OK.

In addition to this, I tried to use CubeMX DDR Test Suite. Having a running SPL I managed to connect to it. The tool correctly recognises the DDR as:

Config name: LPDDR3 16bits 533000kHz
DDR Size: 1 GBits
DDR Frequency: 533.0MHz

Then it stops cooperating with:

Exception in thread "Thread-4843" java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 1

I will appreciate any ideas.

[qyx]

An update, CubeMX DDR test suite is not working simply because the tuning support was removed from the SPL (ref. https://patchwork.ozlabs.org/project/uboot/patch/20211115153214.3.I4594adfd3e69b68a60bdbb2697ae8b97c9f3e8f5@changeid/). This renders the whole tool unusable.

Anyway, there is not much gain in using the Cube MX tool, the same commands can be accessed using a serial terminal.

Results of the previously mentioned tests:

U-Boot SPL 2022.04-rc4-00004-ge349f88a-dirty (Mar 26 2022 - 10:39:31 +0100)
RAM: LPDDR3 16bits 533000kHz
0:DDR_RESET
DDR>next
1:DDR_CTRL_INIT_DONE
DDR>next
2:DDR PHY_INIT_DONE
DDR>next
3:DDR_READY
DDR>test 1
execute 1:Simple DataBus
Result: Failed [0xc0000000: error for bits 0x1]
DDR>test 2
execute 2:DataBusWalking0
running 100 loops at 0xc0000000
Result: Failed [loop 1: error for bits 0xffffffff]
DDR>test 3
execute 3:DataBusWalking1
running 100 loops at 0xc0000000
Result: Failed [loop 1: error for bits 0xedf7dbff]
DDR>test 4 0x100
execute 4:AddressBus
running at 0xc0000000 length 0x100
Result: Failed [0xc0000000: error for address 0xc0000004]

Running test 3 repeatedly gives different, but very similar results:

DDR>test 3
execute 3:DataBusWalking1
running 100 loops at 0xc0000000
Result: Failed [loop 1: error for bits 0xdbedf7ff]
DDR>test 3
execute 3:DataBusWalking1
running 100 loops at 0xc0000000
Result: Failed [loop 1: error for bits 0xf7dbedff]
DDR>test 3
execute 3:DataBusWalking1
running 100 loops at 0xc0000000
Result: Failed [loop 1: error for bits 0xdbedf7ff]
DDR>test 3
execute 3:DataBusWalking1
running 100 loops at 0xc0000000
Result: Failed [loop 1: error for bits 0xedf7dbff]

I tried two different boards, reworked both STM32MP1 and LPDDR3. No other progress so far. I am suspecting a configuration error or a wrong register computation for LPDDR3 by CubeMX. Setting DDR parameters one by one according to the datasheet + relaxing them a bit, CubeMX was able to generate an obviously wrong configuration (eg. overflowing 32 bit registers).

Is there a known working LPDDR3 16bit 533 MHz configuration DTS available @ST?

Thanks.

[PatrickF]

Hi @qyx​ ,

could you share your schematics around supply/ref/signals around DDR interface (both STM32MP15x and LPDDR3 side) ? Sometimes a fresh eye could find mixed up signals (we have the case from time to time).

Using latest Ecosystem (v3.1) with default generated config from latest CubeMx should work.

See also https://community.st.com/s/question/0D53W00001K3tPhSAJ/ddr-device-tree-included-in-cubemx-is-non-existent which might help.

Regards.

[PatrickF]

See also AN5122 and AN5168.

[qyx]

Thank you for the reply, @PatrickF​ 

I have read the mentioned app notes, the only thing I overlooked is the 100R termination resistor on CLKN/CLKP. I added it directly on vias under the LPDDR3 chip now but still no luck.

Regarding the software, u-boot in the v3.1 ecosystem is very old. I was using the upstreamed support in the v2022.04-rc4. I will compare the changes to v3.1 ST's u-boot.

I am attaching the schematic cutout and routing. Individual tracks within byte lanes are matched to 0.1 mm, DQ0-7 is 18 mm, DQ8-15 is 16 mm, CA is 30 mm (the difference of 14 mm is a bit marginal).

Top layer:Bottom layer:

[PatrickF]

Hi, you schematic sound ok. I assume the DDR_VREF is also connected to STM32MP15x.

I confirm the 100ohms on DDR clock was missing in AN5031 (but listed in AN5122 and in our schematics PCB examples).

Otherwise, I cannot comment more on SW version aspects as I have an HW focus.

[qyx]

Thanks for confirming the schematic is correct. Yes, DDR_VREF is connected to STM32MP15x too.

I tried regenerating the DTS again, this is the output of CubeMX:

/*
 * Copyright (C) 2015-2018, STMicroelectronics - All Rights Reserved
 *
 * SPDX-License-Identifier:	GPL-2.0+	BSD-3-Clause
 *
 */
 
/*
 * File generated by STMicroelectronics STM32CubeMX DDR Tool for MPUs
 * DDR type: LPDDR3
 * DDR width: 16bits
 * DDR density: 1Gb
 * System frequency: 533000kHz
 * Relaxed Timing Mode: true
 * Address mapping type: RBC
 *
 * Save Date: 2022.03.28, save Time: 12:34:50
 */
 
#define DDR_MEM_NAME	"LPDDR3 16bits 533000kHz"
#define DDR_MEM_SPEED	533000
#define DDR_MEM_SIZE	0x8000000
 
#define DDR_MSTR 0x00040008
#define DDR_MRCTRL0 0x00000010
#define DDR_MRCTRL1 0x00000000
...

It can be seen that the width is correctly set to 16 bit, despite that CubeMX generated MSTR register value 0x00040008 corresponding to a 32 bit wide DDR. The correct value should be 0x00041008 (half DQ bus width) according to the datasheet.

[PatrickF]

Hi,

which version of CubeMX are you using ?

Tested on v6.4 (the one which must be used with Ecosystem v3.1) and give me MSTR value of 0x00041008 .

See attached file for

 

Regards.

[PatrickF]

previous file was for 400MHz. Find attached file generated for 533MHz

[qyx]

I am using CubeMX 6.5, downloaded a fresh one. I tried both your DTS files with similar results. So I changed the DDR clock to 200 MHz, somehow managed to generate the correct DTS and modified DDR test 3 to get some insight to what can be read from the memory.

Those are the results:

write 00000001 to c0000000
write 00000002 to c0000004
write 00000004 to c0000008
write 00000008 to c000000c
write 00000010 to c0000010
write 00000020 to c0000014
write 00000040 to c0000018
write 00000080 to c000001c
write 00000100 to c0000020
write 00000200 to c0000024
write 00000400 to c0000028
write 00000800 to c000002c
write 00001000 to c0000030
write 00002000 to c0000034
write 00004000 to c0000038
write 00008000 to c000003c
write 00010000 to c0000040
write 00020000 to c0000044
write 00040000 to c0000048
write 00080000 to c000004c
write 00100000 to c0000050
write 00200000 to c0000054
write 00400000 to c0000058
write 00800000 to c000005c
write 01000000 to c0000060
write 02000000 to c0000064
write 04000000 to c0000068
write 08000000 to c000006c
write 10000000 to c0000070
write 20000000 to c0000074
write 40000000 to c0000078
write 80000000 to c000007c
read 00fe0000 from c0000000
read 00000000 from c0000004
read 00000000 from c0000008
read 00000000 from c000000c
read 00000000 from c0000010
read 00000000 from c0000014
read 00000000 from c0000018
read 00000000 from c000001c
read 00000100 from c0000020
read 00000200 from c0000024
read 00000400 from c0000028
read 00000800 from c000002c
read 00001000 from c0000030
read 00002000 from c0000034
read 00004000 from c0000038
read 00008000 from c000003c
read 00000000 from c0000040
read 00100000 from c0000044
read 00200000 from c0000048
read 00400000 from c000004c
read 00800000 from c0000050
read 00000000 from c0000054
read 00020000 from c0000058
read 00040000 from c000005c
read 01080000 from c0000060
read 02000000 from c0000064
read 04000000 from c0000068
read 08000000 from c000006c
read 10000000 from c0000070
read 20000000 from c0000074
read 40000000 from c0000078
read 80000000 from c000007c

Bits 8-15 and 24-31 are read correctly. The rest is corrupted. As the behaviour is the same for both halfwords, it looks like there is a problem with one byte lane.