PROCESSOR-SDK-AM62X: DDR-MARGIN-FW for DDR4 SDRAM

Greetings Kris,

Unfortunately we have no current plans for the firmware to support DDR4 at the moment, though I understand the importance in this issue.

Can you describe the problem you're seeing? Is it failure to train at 800MHz? Data validity issues? A tool that can be useful is running memtester, which is available in our Linux SDK built in. This can help narrow down potential issues with specific bits / byte lanes if it can get past initial training. 

Sincerely,

Lucas

Hi Lucas,

We have been able to diagnose the exact source of the problem.

I will have our Linux team try to run the memtester. I guess, we will have to built a bootable device, in our case USB flash drive, with the Linux SDK ver. 10, is that correct?

We are using Yocto build on our product, which is currently running with the SDRAM at 400 MHz. I guess, we could install the memtester tool there as well?

Hey Kris,

Our device has a couple of boot options, USB boot is indeed one of them. What is your current/preferred boot method being used? Do you have any other peripherals like UART or JTAG on your board? One additional step we can do outside of memtester is if you dump the DDRSS registers, we can examine them for some status bits/registers. This is done easily through CCS which requires JTAG access, but can be done through normal C code as well.

Sincerely,

Lucas

Hi Lucas,

Our custom AM6254 board is setup to boot from USB. Our preferred method is USB flash drive.

However, we have pinned out UART0, which is used for Linux console and we have JTAG connector.

I was able to configure successfully the SDRAM on our custom board with CCS 20.1.0, project-less debug session  running AM62B-P1 EVM gel scripts. However, these scripts configure the 2GB space for 16Gb x 16 chip used on the EVM. 

I have to drop the DDR I/O speed to 400 MHz (200 MHz PLL source) in order to get the DDR running but it configures without error messages at 800 MHz as well. Just when I run the Data_WrRd_test script it returns memory error. It completes successfully at 400 MHz.

I can run the AM62 DDRSS Debug commands and dump the registers.

Also the configuration with the EVM scripts is only 2GB, we have 4GB chip (32Gb x 16).

I tried replacing the AM62x-DDR4-1600MTs.gel (located in C:\ti\ccs2010\ccs\ccs_base\emulation\gel\AM62x\AM62_DDRSS\si_configs) with one generated by the SysConfig DDR4 configuration tool for our 32Gb x 16 chip but it is not working. Is there anything else that needs to be changed?

The 32Gb x 16 DDR4 SDRAM chips are actually two 16Gb x 8 dies in the package so that I wanted to try setting the gel scripts for two 16Gb x 8 chips but couldn't find where the number of chips are set.

Hi Lucas,

I can dump the register with the scripts:

• AM62_DDRSS_CTL_PI_PHY_RegDump
• AM62_DDRSS_SS_RegDump
• Any script from the AM62x folder - ...ccs\ccs_base\emulation\gel\AM62x

Can you help me evaluate the applicable content?

Thanks,

Kris

Greetings Kris,

We can indeed! The AM62_DDRSS_CTL_PI_PHY_RegDump should be all you need for now for dumping from the SoC. Can you get dumps post training at 1600 MT/s and 800 MT/s for comparison?

I spoke with my colleagues as well and it looks like you're also getting the initial configuration sorted out here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1487771/am625-am625-ddr4-configuration-with-ccs-20-1-0-gel-scripts 

Sincerely,

Lucas

Hi Lucas,

I don's see my post from last week so that here it is again.

As I have mentioned, our custom board has Micron MT40A2G16TBB-062E:F SDRAM - a dual 16Gbx8 dice part, which provide 4GB of memory.

The sysconfig configuration is for 16Gbx8 part, which covers the entire 4GB space. (The configuration file are included)16Gbx8.zip 

I am attaching a zip file with two directories that contain the 800MTs and 1600 MTs speeds. The 800MTs memory works, the 1600MTS - does not.

Best Regards,

Kris

Greetings Kris,

Can confirm I'm able to download the zip file with the gels, headers, dumps, and word file containing the test details for 400 vs 800 MT/s (appreciate all of this in one package!). Let me process some of these logs and review what may be going on, I will come back with information as soon as I can or other experiment ideas. I see the CCS experiments so far in the word doc and they make sense, one minor little question to confirm is that do these contents stay the same no matter how many times they are read from the DRAM? There is a continuous refresh button that you can select in the memory browser, most write integrity issues result in the data consistently being read back incorrectly, while a read issue usually manifests as constantly changing data.

Sincerely,

Lucas

Memory Browser.docxThanks Lucas,

I turned the continuous refresh in the memory browser and it appears that the content is continuously read correctly.

- 400 MHz (800 MTs) write and continuous read is correct.

- 800 MHz (1600 MTs) write is wrong while the continuous read, reads the same (wrong) value that was written.

For example, the image below shows the top row of the memory browser that I wrote the following numbers at address 0x8_8000_0000:

a, b, c, d, e, f, aaaaaaaa, bbbbbbbb, cccccccc, dddddddd, eeeeeeee, ffffffff, 0, 0, 0, 0, 0.

/resized-image/__size/640x480/__key/communityserver-discussions-components-files/791/Memory-Browser.jpg

We have performed SI analysis, which clearly show problems with ADDR/CTRL bus. Reports are attached.DDR_report-ddr4-1600-all-nodes-crosstalk.pdfPalPilot - Vorne Sa798.002a 90033200 Post Layout SI.pdf