eMMC always setting busy bit in cmd1 response

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

eMMC always setting busy bit in cmd1 response

ソリューションへジャンプ
4,118件の閲覧回数
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,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 返答(返信)
4,023件の閲覧回数
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,951件の閲覧回数
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,077件の閲覧回数
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,086件の閲覧回数
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