Other Parts Discussed in Thread: TDA4VH
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
