I am using IMX 6Dual Lite processor (MCIMX6U8DVM10AB) and
EMMC 4.51 (MT29PZZZ8D5BKFTF-18 W.95L). The clock(400Khz) is fine from the
processor, but after issuing CMD1 the Present Status Register
(uSDHCx_PRES_STATE) of IMX6DL shows CIHB as 1 which means CMD line of eMMC is
busy and any further commands to the e-MMC will be ignored and it shows
"CMD1 Fail" .I believe, one of the reasons for no response from the
device is incompatible voltage range, but both emmc and the processor are set
Your inputs for this situation would be very helpful.
I have faced the same problem on MCU iMX 6ULL.
I use USDHC1 for SD card and USDHC2 for eMMC (Micron MTFC4GACAJCN-1M WT).
I configure the USDHC2
&MMC_BASE=0x2194000 Per.Set.Field AD:0x0:0x20C4024 %Long 0x70000 4. ;USDHC2_PODF = 5 Per.Set.Field AD:0x0:0x20C401C %Long 0x20000 1. ;USDHC2_CLK_SEL = 1 (PLL2 PFD0 352MHz) Data.Set &MMC_BASE+0x04 %LE %Long 0x00010200 ; blk size,cnt Data.Set &MMC_BASE+0x28 %LE %Long 0x08800020 ; bus width, endian Data.Set &MMC_BASE+0x2C %LE %Long 0x008E08AF ; 400KHz clk Data.Set &MMC_BASE+0x34 %LE %Long 0x007F0037 ; BRR,BWR, TCI, CCI interrupt enable Data.Set &MMC_BASE+0x38 %LE %Long 0x007F0037 ; BRR,BWR, TCI, CCI interrupt enable Data.Set &MMC_BASE+0x44 %LE %Long 0x00100010 ;read/write fifo threshold level 64bytes
then send CMD0
Data.Set &MMC_BASE+0x30 %Long 0xFFFFFFFF ;clear status Data.Set &MMC_BASE+0x8 %Long 0x0 ;arg Data.Set &MMC_BASE+0xc %Long 0x0 ;cmd WAIT 10.ms
and then CMD1
Data.Set &MMC_BASE+0x30 %Long 0xFFFFFFFF ;clear status Data.Set &MMC_BASE+0x8 %Long 0x0 ;arg Data.Set &MMC_BASE+0xc %Long 0x01020000 ;cmd1 WAIT 10.ms
I can see the response on oscilloscope and logic analyzer, but MCU doesn't recognize it and keeps clocking the eMMC.
The CC bit in INT_STATUS register remains 1.
The pins configuration is:
Data.Set ZSD:0x20E0178 %LE %Long 0x1 ; USDHC2_CLK, IOMUXC_NAND_RE_B_USDHC2_CLK.alt1 Data.Set ZSD:0x20E017C %LE %Long 0x1 ; USDHC2_CMD, IOMUXC_NAND_WE_B_USDHC2_CMD.alt1 Data.Set ZSD:0x20E0180 %LE %Long 0x1 ; USDHC2_DAT0, IOMUXC_NAND_DATA00_USDHC2_DATA0.alt1 Data.Set ZSD:0x20E0184 %LE %Long 0x1 ; USDHC2_DAT1, IOMUXC_NAND_DATA01_USDHC2_DATA1.alt1 Data.Set ZSD:0x20E0188 %LE %Long 0x1 ; USDHC2_DAT2, IOMUXC_NAND_DATA02_USDHC2_DATA2.alt1 Data.Set ZSD:0x20E018C %LE %Long 0x1 ; USDHC2_DAT3, IOMUXC_NAND_DATA03_USDHC2_DATA3.alt1 Data.Set ZSD:0x20E01A0 %LE %Long 0x1 ; USDHC2_RESET_B, IOMUXC_NAND_ALE_USDHC2_RESET_B.alt1 Data.Set ZSD:0x20E0404 %LE %Long 0x00010059 ; IOMUXC_SW_PAD_CTL_PAD_NAND_RE_B Data.Set ZSD:0x20E0408 %LE %Long 0x00017059 ; IOMUXC_SW_PAD_CTL_PAD_NAND_WE_B Data.Set ZSD:0x20E040C %LE %Long 0x00017059 ; IOMUXC_SW_PAD_CTL_PAD_NAND_DATA00 Data.Set ZSD:0x20E0410 %LE %Long 0x00017059 ; IOMUXC_SW_PAD_CTL_PAD_NAND_DATA01 Data.Set ZSD:0x20E0414 %LE %Long 0x00017059 ; IOMUXC_SW_PAD_CTL_PAD_NAND_DATA02 Data.Set ZSD:0x20E0418 %LE %Long 0x00017059 ; IOMUXC_SW_PAD_CTL_PAD_NAND_DATA03 Data.Set ZSD:0x20E042C %LE %Long 0x00017059 ; IOMUXC_SW_PAD_CTL_PAD_NAND_ALE
SD Card on USDHC1 works perfectly. By the way, waveform of CMD line of SD Card is a little bit better
The same configuartion and eMMC chip i use in another custom board with MCU MXRT1051 and it MCU receives response properly.
The main reason why MCU ignores the answer from eMMC is besides configuring SW_MUX_CTL_PAD_* registers i had to configure Daisy registers for these pins as well.
After I added the following lines to peripherals initialization script MCU recognized the answer from eMMC.
Data.Set ZSD:0x20E0670 %LE %Long 0x2 ; IOMUXC_USDHC2_CLK_SELECT_INPUT.NAND_RE_B_ALT1 Data.Set ZSD:0x20E0678 %LE %Long 0x2 ; IOMUXC_USDHC2_CMD_SELECT_INPUT.NAND_WE_B_ALT1 Data.Set ZSD:0x20E067C %LE %Long 0x2 ; IOMUXC_USDHC2_DATA0_SELECT_INPUT.NAND_DATA00_ALT1 Data.Set ZSD:0x20E0680 %LE %Long 0x2 ; IOMUXC_USDHC2_DATA1_SELECT_INPUT.NAND_DATA01_ALT1 Data.Set ZSD:0x20E0684 %LE %Long 0x1 ; IOMUXC_USDHC2_DATA2_SELECT_INPUT.NAND_DATA02_ALT1 Data.Set ZSD:0x20E0688 %LE %Long 0x2 ; IOMUXC_USDHC2_DATA3_SELECT_INPUT.NAND_DATA03_ALT1
And finally I got data from eMMC
CMD1 resp: 0x0C0FF8080 CID register [127:104] 0x13014E [103:72] 0x51324A35 [71:40] 0x3441100D [39:8] 0x0E57558C5 Dual port programming mode enabled -------(e)MMC FLASH-------- Manufacturer ID: 0x13 Card/BGA: BGA OEM/Application ID: 0x14E Product name: Q2J54A Product revision: 1.0 Serial number: 0xDE57558
i guess @dharitrihazarik and others have experienced the same problem.
I am using different NXP chipset from i.MX processor family but I ran into exactly the same issue - eMMC card replies with 0x00FF8080 to CMD1. In my case the card used to be working for a while but then it went to busy state and nothing helps.
I could not see which reply answered the original question. could you share the reply please?
1. SD card follows SD Card Association and emmc follows Jedec. You can see the in the spec, it mentions it is different spec. Yes, it is similar. that why, linux driver share the sdhci.c as controller driver. and the chip uses the same controller as silicon design.
2. It is sequence diagram in the spec. I just see some separate operations here.
3. I did n't see wave form compare to the spec and point out, it is wrong.
4. quote georgemakarov's test result, no wrong with the single command and response.
CMD1 resp: 0x0C0FF8080
Dual port programming mode enabled
Manufacturer ID: 0x13
OEM/Application ID: 0x14E
Product name: Q2J54A
Product revision: 1.0
Serial number: 0xDE57558
5. i.MX6 family is deployed as mass production chip with millions. So it has such basic problem. I don't think so. if so, point out the wrong with the spec. At least, till now, we did get such simple issue with linux driver.
Just wanted to add up to above:
Basically, we have checked with same .cmm file on both our board as well as Sabre board. We find that the response is there (observed in oscilloscope on both scenarios), but host in our board is not capturing it to their data registers (CMD Response registers are showing 0x0) whereas Sabre board host is capturing the proper response (CMD response register showing 0x00FF8080).
From Hardware perspective we are running at less than 400Khz and we have checked all the timimg parameters and signal integrity too.
Can you please guide us where and what all things we could check further?
We are getting response from eMMC device, so it must not be defective, but the IMX processor is not being able to capture the CMD1 response. We have checked the signals with oscilloscope. They resemble exactly same as produced by the Sabre board emmc till CMD1.
Many thanks for the suggestion.
Presently, am not booting the eMMC device but trying to communicate with it. The issue that I am facing presently with the communication between eMMC and IMX processor is that after issuing CMD1 argument as 0XC0FF8080 or 0x40FF8000 and cmd as 0x1020000, I get a response from emmc as 0x00FF8080. But this response is obtained after decoding the generated waveform and is not detected in the software response(using .cmm file with trace32). Might be the reason for this is the host is not being able to capture the response send by the eMMC.
I would further like to add that according to JEDEC eMMC standard, the device gives a response of 0X00FF8080 when the device is busy and hence should repeat the cmd1 till the device gets to ready state. I have repeated the cmd1 1000 times, but still at the end I get the result as CMD1 Fail.
From hardware perspective, I have checked all the possible cases regarding timing parameters , rise time, fall time of the signal. They all seem to be fine.
Please provide your valuable suggestions.
Thanks & Regards,
Have checked the .cmm file with sabre evaluation board, its working fine. But, in our board we are getting stuck on the initialization phase of emmc. As stated above, the IMX is not being able to capture the response from Card after issuing CMD1.
reason may be defective eMMC, so one can change it with SDB board.
Also there may be layout errors on custom board, one can check
signals with oscilloscope.
one can check eMMC connections, in particular pull-ups on control lines,
refer to Sabre schematic
as for software - check that SION bits are set for i.MX6DL iomux control signals.
One can try to test with uboot, included in latest BSP:
Board Support Packages (29)
L3.14.52_1.1.0_MX6QDLSOLO (REV L3.14.52_1.1.0)
Note: If this post answers your question, please click the Correct Answer button. Thank you!
Thanks for the reply. I have checked eMMC connections, pull-ups(47K) on control lines(CMD),and have also referred to Sabre schematic. The schematics in our design seems to be fine. From the software perspective, i.MX6DL iomux control signals bits are set as per requirement. Still the CMD1 is failing.
Today when we analysed the waveform that we get on the command line (CMD1), it is observed that there is a proper response for the CMD1 (with argument 0xC0FF8080) from the card. From the waveform, we decoded the response as 0x00FF8080 (the 8080 bytes means the card is a dual voltage range one). As per the JEDEC
standards document it is understood that the card is responding back with the power up status bit as busy(bit no. 31) and it is in byte access mode(bit no. 30 and 29).
As per emmc datasheet State diagram, this condition occurs when there is non-compatible voltage range card OR if host cannot use sector mode in cards >2GB.
Since we have checked the power levels of emmc and have got the response as 8080; I believe we can rule out
the non-compatibility voltage range and suspect the access mode as the issue here.
Your suggestions for these would be very helpful.
Thanks & Regards,