- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Tool/software:
Questions about TDA4VM with DDR MT53E512M32D1ZW-046 AUT:B training:
1. By which register is TDA4VM configured for the internal DDR registers MR11, MR12, MR14 and MR22? Is the DDRSS_CTL_179 of the TDA4VM modifying the internal MR12 register of the DDR?
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?
3. Will the MR11, MR12, MR14 and MR22 registers in the DDR be updated after command bus training, read DQ training and write training?
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?
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?
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.
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.
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.
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'.
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
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?
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
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.
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.
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.
