TDA4VM-Q1: Questions about TDA4VM DDR training

Pengpeng Zhangpengpeng said:

1. By which register is TDA4VM configured for the internal DDR registers MR11, MR12, MR14 and MR22?

The TDA4 DDRSS uses the values programmed in the DDRSS PI register set to program the LPDDR4 mode registers during initialization. As an example, MR11 is defined in the following registers (bits 31:24 of each):

DENALI_PI_281
DENALI_PI_283
DENALI_PI_285
DENALI_PI_287
DENALI_PI_289
DENALI_PI_291
DENALI_PI_293
DENALI_PI_295
DENALI_PI_297

Pengpeng Zhangpengpeng said:

2. When is the command bus training, read DQ training, and write training of TDA4VM executed respectively? Does the TDA4VM automatically DDR train itself when the ambient temperature changes? Is dynamically adjusting refresh rate relevant to ddr training?

All training happens during initialization. During mission mode, the write DQ training algorithm should also run periodically. The periodic re-train of the write DQ delay was enabled as part of version 0.5.0 of the DDR register configuration tool (earlier versions do not enable periodic training).

Pengpeng Zhangpengpeng said:

3. Will the MR11, MR12, MR14 and MR22 registers in the DDR be updated after command bus training, read DQ training and write training?

MR11 and MR22 do not get trained. The values in MR12 and MR14 will be updated after the respective training is executed during initialization. 

Pengpeng Zhangpengpeng said:

4. In the jacinto7 DDRSS regconfig tool, configure MR12 register CA VREF 25.6% (corresponding to 0x12 in DDR datasheet) in the DRAM IO configuration.
However, the code DDRSS_CTL_179 produced by tool is 0x27270056, and the corresponding percentage of 0x27 is 38.3%, which does not correspond to DDR datasheet. How to convert the value generated by tool and the value in DDR datasheet?

I think the table you are looking at in the memory datasheet (table 53) is for LPDDR4x (0.6V IO). LPDDR4 and LPDDR4x have different MR12 / MR14 values. 

Pengpeng Zhangpengpeng said:

5. We measured different boards, and the reading value of DDRSS_CTL_179 is always 0x27270056 after starting up and after starting up for a period of time. This value also remains unchanged after the temperature changes (85°C to -40°C), and this value also remains unchanged after low temperature restart. When does DDR perform training?

The TDA4 DDRSS Controller registers will not reflect the trained MR12 / MR14 values. You can observe the trained MR12 / MR14 values from the TDA4 DDRSS PI registers (see list below), where MR12 = bits 7:0 and MR14 = bits 15:8 of the registers. There are 8 copies of the register because TDA4 supports two channels and two ranks (4x total) , and the LPDDR4 memory supports two frequency copies.  

DDRSS_PI_282
DDRSS_PI_284
DDRSS_PI_286
DDRSS_PI_288
DDRSS_PI_290
DDRSS_PI_292
DDRSS_PI_294
DDRSS_PI_296
DDRSS_PI_298

Pengpeng Zhangpengpeng said:

6. When Micron Laboratory helped us test the signal integrity, they reported that the MR12 and MR14 we provided were inaccurate, and the CA VREF they finally used was 20.5%, and the DQ VREF was 21.5%. And the test passed.

I do not quite understand the question.

Pengpeng Zhangpengpeng said:

7. We have a board that will restart abnormally after running at a low temperature (-40℃) for a period of time, such as 2 hours, and it is normal at room temperature. May I ask how to capture log to help determine whether the restart is caused by abnormal DDR? The current log captured by the uart interface does not change before the restart.

I don't know that abnormal DDR would necessarily cause the device to restart. Typically, data corruption impacting instruction code would result in a CPU crash. You could try running a memory test though to see if it generates any failures. The Linux SDK comes packaged with memtester that can be executed from the terminal window.

Regards,
Kevin

Kevin S said:

All training happens during initialization. During mission mode, the write DQ training algorithm should also run periodically. The periodic re-train of the write DQ delay was enabled as part of version 0.5.0 of the DDR register configuration tool (earlier versions do not enable periodic training).

Our operating system is QNX，DDR register configuration tool version is 0.10.0，The DDRSS_PI_280 value configured by the tool is 0x00160f27, I actually test the DDRSS_PI_280 use command 'k3conf read 02992460'and get 'Value at addr 0x2992460 = 0x00161d13', and 'Value at addr 0x2992460 = 0x00161e13' sometimes after boot initialization，Wait for a period of time to retest, the value remains the same .Is the periodic re-train of the write DQ delay automatically ?

I think the table you are looking at in the memory datasheet (table 53) is for LPDDR4x (0.6V IO). LPDDR4 and LPDDR4x have different MR12 / MR14 values. 

YES,I got the wrong table, use table 200 the Vref value match with the DDR register configuration tool's value.

Kevin S said:

The TDA4 DDRSS Controller registers will not reflect the trained MR12 / MR14 values. You can observe the trained MR12 / MR14 values from the TDA4 DDRSS PI registers (see list below), where MR12 = bits 7:0 and MR14 = bits 15:8 of the registers. There are 8 copies of the register because TDA4 supports two channels and two ranks (4x total) , and the LPDDR4 memory supports two frequency copies.  

I find DDR configuration tool frequence set 1 and set 2 are the same,set 0 is 55Mhz ,so which is the system operating frequence ,set 1 or set2 ?

I still confused, what is the difference between DDRSS_PI_280 register and DDRSS_CTL_179, the description are both 'Data to program into memory mode register 12 for chip select 0'.

Kevin S said:

6. When Micron Laboratory helped us test the signal integrity, they reported that the MR12 and MR14 we provided were inaccurate, and the CA VREF they finally used was 20.5%, and the DQ VREF was 21.5%. And the test passed.

According to DDR configuration tool MR12, we configured 0x27, Vref=25.6%*VCC=282mV, Micron's actual test believes that Vref=225mV is easier to pass the test, but the actual test center of the eye is still more inclined to the low level of CS. The CK center to the CA eye center is fine, slightly to the left ,use Vref =225mV.Micron tester thinks it's acceptable. I think there are some problems with the delay between CS and CK, whether this needs to be changed? And I just ran MR12=0x13,Vref=17.6% read on my own board, Vref=193.6

Kevin S said:

I don't know that abnormal DDR would necessarily cause the device to restart. Typically, data corruption impacting instruction code would result in a CPU crash. You could try running a memory test though to see if it generates any failures. The Linux SDK comes packaged with memtester that can be executed from the terminal window

We found the problem in the process of doing a high and low temperature DDR stress test, using the memtester tool. The memterster log did not show any exception before restarting, but suddenly stopped rotating, and then waited for about 16 seconds for the system to restart. It was strange that the restart caused by abnormal board power-on usually did not delay by 16 seconds. Therefore, I do not think there is a problem with the power on the board, and this board is already a mass production board, but the DDR model has been changed recently. We have tested a total of 4 boards, and the other three boards have no problem in the high and low temperature pressure test at room temperature. Only this board will restart at low temperature, sometimes after two hours of operation, sometimes after 60 hours of operation, but there is no restart problem at room temperature, and it will restart at low temperature regardless of whether the DDR pressure script is run. Could this reboot have something to do with the above?

Pengpeng Zhangpengpeng said:

Is the periodic re-train of the write DQ delay automatically ?

Periodic write DQ training occurs automatically, but only re-trains the delay.

Pengpeng Zhangpengpeng said:

I find DDR configuration tool frequence set 1 and set 2 are the same,set 0 is 55Mhz ,so which is the system operating frequence ,set 1 or set2 ?

Version 0.10.0 of the DDR config tool enables all frequency sets for TDA4VM; however, set 2 is where the system will operate after initialization. 

Pengpeng Zhangpengpeng said:

I still confused, what is the difference between DDRSS_PI_280 register and DDRSS_CTL_179, the description are both 'Data to program into memory mode register 12 for chip select 0'.

It is overlap in logic. The DDR sub-system is made up of a controller and PHY (the PHY includes the PI, or "phy independent" block). The PHY was designed to be able to perform basic functionality without a controller, such as initializing the LPDDR4 memory. The controller also has capability to read and write to the LPDDR4 mode registers. However, TDA4x only supports using the PHY to initialize the LPDDR4 memory. Thus it is the PI MR registers which are of relevance during initialization.

Pengpeng Zhangpengpeng said:

According to DDR configuration tool MR12, we configured 0x27, Vref=25.6%*VCC=282mV

This is just a default setting from the config tool. MR12 will change during initialization. Can you read out the registers below?

DDRSS_PI_282
DDRSS_PI_284
DDRSS_PI_286
DDRSS_PI_288
DDRSS_PI_290
DDRSS_PI_292
DDRSS_PI_294
DDRSS_PI_296
DDRSS_PI_298

Pengpeng Zhangpengpeng said:

but the actual test center of the eye is still more inclined to the low level of CS

From the scope plots, the voltage swing of CS appears over 600 mV while the voltage swing of CA appears less than 450 mV. This issue here is that CA / CS share VREF on the LPDDR4, so one of the two will have a VREF not at the mid point. 

One thing you might try - set CA drive strength to 40 ohms, CS drive strength to 80 ohms, and CA/CS ODT to 80 ohms (or RZQ/3). 

Pengpeng Zhangpengpeng said:

We found the problem in the process of doing a high and low temperature DDR stress test, using the memtester tool. The memterster log did not show any exception before restarting, but suddenly stopped rotating, and then waited for about 16 seconds for the system to restart.

You originally mentioned low temperature, but now also mention high temperature. If at high temperature, it could be a thermal shut down which I think was added logic in more recent SDKs. 

If you suspect DDR though, you could try reducing DDR frequency as a debug step. But if DDR is actually marginal, I would suspect that the device would not always fail in the same manner. 

Regards,
Kevin

Kevin S said:

This is just a default setting from the config tool. MR12 will change during initialization. Can you read out the registers below?

DDRSS_PI_282
DDRSS_PI_284
DDRSS_PI_286
DDRSS_PI_288
DDRSS_PI_290
DDRSS_PI_292
DDRSS_PI_294
DDRSS_PI_296
DDRSS_PI_298

In order are as follows：（DDRSS_PI_282 ：CS1,frequency set0 ,our LPDDR4 use CS0 and CS1）
Value at addr 0x2992468 = 0x00160000
Value at addr 0x2992470 = 0x00161f14
Value at addr 0x2992478 = 0x00161d13
Value at addr 0x2992480 = 0x00160000
Value at addr 0x2992488 = 0x00161f13
Value at addr 0x2992490 = 0x00161c12
Value at addr 0x2992498 = 0x00160000
Value at addr 0x29924a0 = 0x00161c14
Value at addr 0x29924a8 = 0x00161b14

Kevin S said:

One thing you might try - set CA drive strength to 40 ohms, CS drive strength to 80 ohms, and CA/CS ODT to 80 ohms (or RZQ/3). 

I find tCIVW-L/tCIVW-R/VCIVW-Mask-TOP/VCIVW-Mask-BOTTOM sepc is just greater than 0ps/0mV is OK.Since the  test report shows “In spec” ，We have currently imported the default DDR configuration into production .

Is it a serious problem that CK is not in the middle of CA and CS's eyes？Whether it must be improved ?

If I want to continue to improve the problem that CK is in the middle of CS/CA's eyes,I should trying to keep CS and CA amplitudeas close together as possible, right?

Please help check ，Whether to modify according to the red box in the following table is OK ？I can not find the CS ODT termination configuration option.

By the way, another project，use the same TDA4VM with the same type number of the LPDDR4，And use the same DDR register configuration，I compared the reports of these two projects and found that the CK amplitude of the other project was lower, first project,the VIHdiff-CK is 612mV,second project, the VIHdiff-CK is 335mV,Is this normal？Below is a test image from another project.

Kevin S said:

You originally mentioned low temperature, but now also mention high temperature. If at high temperature, it could be a thermal shut down which I think was added logic in more recent SDKs.

Only the problem of automatic restart will be repeated at low temperature, and it has not been repeated for 3 days at room temperature.There is no overtemperature during the high temperature test, and we monitor the temperature of the SOC through the thermocouple.

Kevin S said:

If you suspect DDR though, you could try reducing DDR frequency as a debug step. But if DDR is actually marginal, I would suspect that the device would not always fail in the same manner.

In the near future, we will try to reduce the DDR rate to 1333MHz to see if the problem reappears.