eMMC always setting busy bit in cmd1 response

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

eMMC always setting busy bit in cmd1 response

Jump to solution
3,211 Views
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

 

 

 

 

Labels (1)
0 Kudos
1 Solution
3,043 Views
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.

View solution in original post

0 Kudos
4 Replies
3,116 Views
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 Kudos
3,044 Views
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 Kudos
3,170 Views
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 Kudos
3,179 Views
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