I am using pic18lf452 to write image data(HEX) on MMC and then read back.
MCC 18 platform is used while ICD 2 is used for programming.
I have simulated code on PROTEUS and its working. But on hardware I am facing the problem.

pic and mmc communicating in SPI mode.
MMC is accepting cmd0(reset) and cmd1(initialization), but not other cmds. I am sending cmd16 after cmd0&1 to set block length but every time i get a timeout.
I have used voltage divider to bring 5v of pic to 3.3v for mmc.
If anybody has any idea regarding this please post.
Thanks in advance.

Voltage dividers are quite bad for this usage. It's very poorly regulated and ineffecient. Varying loads means changing voltages. The mmc might easily lock up if it can't handle voltage swings around the 3.3V point very well.

"The default block length is as specified in the CSD (512 bytes). A set block length of less than 512 bytes will cause a write error. The only valid write set block length is 512 bytes. CMD16 is not mandatory if the default is accepted."

I don't know if MMC cards are just like SD cards for this command, but they are identical in many ways, so maybe your MMC card has a restriction on what a valid block length may be.

Maybe it would make sense for you to first go with the default blocklength of 512 bytes, get basic data reads and writes working, then try changing the blocklength if you really need to.

Thanks 4 ur ideas
@davebee
I made some changes in my code. Now I am sending mmc block write cmd instead of cmd for setting blocklength after cmd 0&1. But still I am getting a timeout, that is cmd is not accepted. so ultimately the situation is same.

If the card is initialized properly, you should be able to read the card information register with command 9. Many of the information fields have known bit settings, so they make good tests of whether your read command is being accepted and whether your data retrieval code is correct.

Another thing you could do is format the card for a PC FAT filesystem then verify that the DOS FAT signature $55AA is correctly read from the last two bytes of sector zero.

I would say forget about trying to write to the card until you can show a working read.

But I want to share something about latest status as I have 18LF452, I can operate it at 3.3V also. In that case there is no need of voltage divider before mmc and I have connected spi pins of pic and mmc directly but still write cmd wasn't accepted after cmd0 &1.

The host must poll the card (by repeatedly sending CMD1) until the in-idle-state bit in the card response indicates (by being set to 0) that the card has completed its initialization processes and is ready for the next command.

In my implementation, which responds only to manual input from the keyboard, it takes two CMD1 commands before the "In-Idle-State" bit goes to '0'. You did not say what value was returned in the R1 status byte, but I'm guessing it was a value like 0x05, which means that the card was still "In-Idle-State" and there was an illegal command/switch.

After the second CMD1 the "In-Idle-State" bit was 0 and I have successfully issued commands CMD10 to read the CID register, CMD13 to read the status, and CMD58 to read the OCR.

@ papabravo
In my code i am sending cmd0 once after that cmd1 with polling ie i ll be sending cmd1 again n again (255 times before timeout) until it gets 0x00.
I am comparing return of SPI_Read with 0x00 only.
right now i am not with hardware but at best of my knowledge i was also getting cmd1 acceptance response after sending it twice.

Looking over code that's worked for me, I've found that after enabling the CS, sending $51, sending the 4 byte address, then $FF, I had to loop repeatedly, several hundred times sometimes, sending $FF and looking for $FE in the response, in order to allow the card time to perform the read.

Could it be that your mmc_response($FE) isn't allowing the card enough time before it declares failure?

@davebee
here is my mmc_response function
I hav one doubt, i can check for response ($FE) once i get cmd response as ($00). In my code iam getting timeout at cmd response itself.
I hav plan to make few changes in code, i will implement and thn come back.

Thanks

int mmc_response(unsigned char response)
{
long count = 0x2FFF; // 16bit repeat, it may be possible to shrink this to 8 bit but there is not much point
unsigned char r;

Hello to all
In my ckt i am getting 0xFF as cmd response for any cmd i send after cmd0&1 which is very doubtfull as no cmd response can have MSB 1,
while i am getting correct cmd response for cmd 0 &1.
is it a hardware problem???
any idea................................