- 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.
Hi TI Experts,
Customer is working on TDA4VH SDK9.0 customer board, and the boot mode is SPL.
They have no problem of booting using SD card before.
Recently as their project is going to reach to mass production, they need to change to use eMMC to boot, and have found the following issue.
Firstly they are using Western Digital (owns SanDisk) SDINBDG4-16G-XI1, the corresponding data sheet is provided below.
The problem is that it will have high possibility of eMMC boot failed, only a small possibility that the eMMC could boot successfully. (in the room temperature)
When the eMMC boot failed, it will have the following 3 different error log.
Error log 1:
Error log 2:
Error log 3:
If the eMMC boots successfully, it will have the below successful boot log (HS400) :
We have done both of HW and SW debugging tests, and I have summarized them below, please have a look of the results, thanks!
Test 1
We have tried increasing the below regmap_red_poll_timeout parameter from 20 to 2000, the result shows that the possibility of eMMC boot success increases a little bit, but still has chance to boot fail as discussed above.
Test 2
We have checked the waveform of Clock & D0 & DS, and it looks normal below.
Test 3
We have tested the eMMC delay, and the tested data looks normal below.
Test 4
We have tested in the high speed mode (50MHz), the hold time of CMD signal seems not enough as required by JESD84-B51 standard. Also in the high speed mode, the waveform can only be captured if the Emmc boot is successful, and it can only be captured in the kernel boot stage. Please have a look below.
As we can see from the above test data, the input CMD hold time is 1.706ns.
However, as required from the standard shown below, the minimum value of hold time should be 3ns.
Would this result be related to our Emmc boot problem?
We are suspecting that means the timing margin is not sufficient, but we are not very sure.
Test 5
Based on the test 4 result, we have tried the following experiment. In the below MMC0_CMD line (the picture shows the default HW schematic diagram without any changes), we have tried change the R3808 from 0Ω to 10Ω，and add a very small capacitor C4918 (4.7pF) in parallel.
The result shows that, after this HW changing, we could boot eMMC successfully in HS400 mode every time.
However, there is the following reason that we could not take this solution to fix this issue.
We have double checked the time series of clock & CMD in the default HW setting shown below, it actually already satisfies the Bus Timing Specification in the eMMC standard <JEDEC Standard No. 84-B51 >
After making the above HW changes, the time series of Clock & CMD is not as good as before shown below.
As we could see, although we could boot eMMC successfully by this method, the waveform is getting poor (not like an expected square wave).
Also, we have checked the CMD hold time after adding the resistor & capacitor, we could see the hold time is closer to the required minimum requirement of 3ns (change from 1.7ns to 2.0ns). If a larger capacitance is added, the hold time will reach the standard requirement 3ns, but a larger the capacitance added the poorer the waveform will be, it would be completely not like a square wave, so we could not take this solution.
Another important information for our design is that, we have 2 generations of our boards. In the first generation, the PCB trace length is 1770mil. In the second generation, the PCB trace length is optimized to 1370mil. For the same SW setup, it could boot eMMC at HS400 mode successfully in the first generation boards, but for the second generation boards, they will have the above problems. We have tested the PCB trace length of TDA4VH EVM is around 2000mil. Could we suspect the timing margin for the default EVM design is not very sufficient, so that if we optimize PCB trace length, it might have this problem?
We may need get some suggestions based on our experiment results, thanks!
We have also found that there are some similar posts recently having the same error log shown below.
We hope to get the further debugging suggestions based on these information, thanks for your help!
Kind Regards,
Kevin
Hi TI Experts,
Customers have tried performing the following test also.
Step 1: Decreasing the eMMC speed in the Uboot stage from HS400 to HS200
Step 2: Keeping the eMMC speed in the kernel boot stage the same as HS400, which means after the board booting up, the final eMMC speed read in the system is still HS400.
Then the second generation boards with 1370mil PCB trace length could also boot eMMC successfully now.
The only change with default SW setting is decreasing emmc speed in the uboot stage only.
So let me make a short summary below.
For the first generation boards with 1770mil PCB trace length, ±10mil trace length mismatch, and 2.1ns hold time, the HS400 is supported on both uboot and kernel boot stage.
For the second generation boards with 1370mil PCB trace length, ±30mil trace length mismatch, and 1.7ns hold time, the HS400 is only supported on the kernel boot stage, but in the uboot stage we have to decrease to HS200 to boot.
Based on the above findings, we have also checked 2 more information from the JESD84-B51 standard shown below.
1: The CMD input timing requirement for HS400 and HS200 is the same, which is minimum 3ns. Although in both of the 2 generation boards, the measured hold time is less than the minimum hold time, but if the requirement is the same, then we do not know why HS200 in uboot boot stage could work but HS400 could not for the second generation boards. Does this parameter matter and how it relates to the uboot emmc speed?
2: The trace length mismatch should be minimal up to ±1mm which is equivalent to ±40mil. Although in our second generation boards, the measured trace length mismatch is ±30mil and it is greater than that of our first generation boards with ±20mil, it still satisfies the requirement ±40mil. Hence we do not think this could cause the problem right?
Please help analyze these information and experiment results we have so far.
We are looking forward to get some suggestions and further debugging ideas based on that.
Also, would there be any tool available that is useful to debug this issue?
Thanks a lot!
Kevin
Hi Matt,
Thanks for your reply.
Yes this problem only happens on eMMC mode, and only happens on customer's second generation boards.
This problem is not related to SDK versions but related to hold time and PCB trace length mismatch.
Different SDK versions on the second generation boards have the same results.
Same SDK version on first generation boards could pass, but on the second generation boards will fail.
For the error logs, they seem occur randomly.
As for the previous summary, the first generation boards have 2.1ns hold time and 10mil PCB trace length mismatch, and the second generation boards have 1.7ns hold time and 30mil PCB trace length mismatch.
We also have tested our TDA4VH EVM board, and measured the hold time for EVM board also does not meet the JESD84-B51 standard which requires 3ns. The result is around 1.9ns shown below.
So based on this result, could we think that hold time is not a must requirement?
If so, then the only difference between the second generation boards with EVM board or the first generation boards is the PCB trace length mismatch.
May I know a 30mil mismatch is acceptable or not, as seeing from our datasheet less than 1mm (40 mil) is okay.
Kind Regards,
Kevin
Hi TI Experts,
Updating the current status.
If we use HS400 mode in the first generation boards (second generation boards have eMMC error mentioned above) without eMMC error, the speed is still similar to HS200. However, from the eMMC datasheet, it claims the HS400 is supposed to be supported.
Our experiment test results are provided below.
The command we used is:
#cat 003-fio-test.sh
#!/bin/sh
rm -rf fiotest_read fiotest_write
echo "\n\n======================= fio read test ==============================="
fio -filename=fiotest_read -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=16k -size=1G -numjobs=2 -runtime=100 -group_reporting -name=mytest
echo "\n\n======================= fio write test =============================="
fio -filename=fiotest_write -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=1G -numjobs=2 -runtime=100 -group_reporting -name=mytest
The result we got is (read & write 1G file):
HS400 read: 137MB/s
HS400 write: 75.7MB/s
HS200 read: 132MB/s
HS200 write: 70.5MB/s
Kind Regards,
Kevin
Hi Diwakar,
Thanks for your reply!
In customers' first generation boards, the eMMC boot does not have any error or recovery, also when we do the eMMC HS400 performance test, there is also no error or recovery shown on the linux.
Please see the below log for eMMC read & write performance test, thanks!
eMMC read at HS400:
eMMC write at HS400:
For their second generation boards, due to the PCB trace length mismatch increases from 10mil to 30mil, it will have the above mentioned error and stuck at Uboot stage.
We also suspect this relates to the hold time. In the JESD84-B51 standard, the minimum hold time requirement is 3ns. And this is also the only data that not meet the requirement shown in our experiment results. For customers' first generation boards, the hold time measured is 2.1ns, for their second generation boards, the hold time measured is 1.7ns. They measured the EVM hold time is about 1.9ns (this may need our HW experts to double check and validate it).
Kind Regards,
Kevin
Hi Kevin,
We also suspect this relates to the hold time. In the JESD84-B51 standard, the minimum hold time requirement is 3ns. And this is also the only data that not meet the requirement shown in our experiment results. For customers' first generation boards, the hold time measured is 2.1ns, for their second generation boards, the hold time measured is 1.7ns. They measured the EVM hold time is about 1.9ns (this may need our HW experts to double check and validate it).
We actually don't spec hold/setup times for speed modes which use tuning. Please refer to the datasheet for transmit switching requirements.
Best Regards,
Matt
