eMMC always setting busy bit in cmd1 response

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

eMMC always setting busy bit in cmd1 response

跳至解决方案
4,117 次查看
iann
Contributor III

Hi we're using a LPC54608 with an external sandisk (sdinbda6-64g) eMMC memory device which is failing to complete the initialisation phase. (using sdk 2.7.0)

Having looked at the clk, cmd and d0 lines on the scope I can see the processor is sending cmd0 to put it into idle state then is in a constant loop sending cmd1 with the reply always showing bit 31 of OCR as busy (0).

The eMMC part is connected to 3V3 for VCC and VCCQ at 1V8 with power rails measured at 3.32 and 1.81

Is there anything on the nxp processor side that can stop the init phase?  Or any extra debug that can be turned on?

Kind regards

Ian

 

 

 

 

标签 (1)
0 项奖励
回复
1 解答
3,949 次查看
iann
Contributor III

To close this off.

In the end we had to change the emmc part to an ISSI one which has now come up first time with no problem.

Below is the start up sequence showing the handshaking to up gears through the clock speeds.

init from 2nd batch.png

The SanDisk part had a line in the hardware design manual that it needed the I/O and core voltage in a sequence outside of the normal jedec spec.

在原帖中查看解决方案

0 项奖励
回复
4 回复数
4,022 次查看
Alexis_A
NXP TechSupport
NXP TechSupport

Hello @iann,

What you could do is to modify the MMC_SendOperationCondition to include the MMC_GoIdle that will call the CMD0 again.

Best Regards,

Alexis Andalon

0 项奖励
回复
3,950 次查看
iann
Contributor III

To close this off.

In the end we had to change the emmc part to an ISSI one which has now come up first time with no problem.

Below is the start up sequence showing the handshaking to up gears through the clock speeds.

init from 2nd batch.png

The SanDisk part had a line in the hardware design manual that it needed the I/O and core voltage in a sequence outside of the normal jedec spec.

0 项奖励
回复
4,076 次查看
iann
Contributor III

Hi Alexis,

Thanks for getting back to me, this is on a custom board. A previous prototype board worked with a different eMMC chip from ISSI, that board also had quite different power up characteristics for the Core VCC and the I/O VCCQ which we're currently investigating.

I've looked at the latest sdk changes and can see there's a change to the cmd 1 retries which I've implemented in our version. I was using the mmc example as a test.

Is there a way the sdk driver can be changed to issue another cmd 0 after the cmd 1 number of retries has been reached so it will try again after issuing a reset(cmd0) ?

Cheers

Ian

0 项奖励
回复
4,085 次查看
Alexis_A
NXP TechSupport
NXP TechSupport

Hello @iann ,

Are you using a custom board or a development board? If you're using a custom, could you try replicating this in one of our development boards?

Are you using an SDK example to test this?

Also, the latest SDK available is 2.8.0. so I suggest updating it.

Best Regards,

Alexis Andalon