Some MMC cards were failing repeatedly on Omap1710 in the card
select command CMD7. Doing an extra status inquiry when leaving the card
identification mode removed the problem. This is possibly Omap1710 mmc
controller only problem, but might also also appear on other mmc
controllers.
So far, the problem occured only on ATP and Transcend cards when the card
have already been detected and then mmc_detect_change() is called to
check if any new cards have been inserted. After CMD2 the next card
select command CMD7 fails due to illegal command error.
I don't know why only ATP and Transcend have this problem and why
doing status inquiry CMD13 helps. Status inquiry command is neutral
and is claimed to not change the card state in the MMC spec. :-)
The order of commands must be CMD13 first, then CMD7. CMD13 fails
also due to illegal instruction error after CMD2 but after this the
card is back to its senses.
If CMD7 is run first, and CMD13 once CMD7 is seen failing, this fails
to bring the card back to its senses. Then the CMD7 fails repeatedly
due to command timeout before and after CMD13.
I got rid of the problem by simply adding call to mmc_check_cards()
at and of mmc_setup() function, which is perhaps an overkill. One could do
it also in mmc_rescan() after switching back to higher clock.
Jarkko Lavinen
On Mon, Oct 03, 2005 at 04:54:45PM +0300, Jarkko Lavinen wrote:
> So far, the problem occured only on ATP and Transcend cards when the card
> have already been detected and then mmc_detect_change() is called to
> check if any new cards have been inserted. After CMD2 the next card
> select command CMD7 fails due to illegal command error.
I'm not surprised. CMD2 is part way through the initialisation
sequence, so no one should be sending a CMD7.
After a CMD2, the next expected command is a CMD3 for MMC cards (maybe
not SD cards).
Given the code, I don't see how you can possibly be sending a CMD7
before the initialisation has completed. You need to find out why
a CMD7 is being sent after CMD2.
> I got rid of the problem by simply adding call to mmc_check_cards()
> at and of mmc_setup() function, which is perhaps an overkill. One could do
> it also in mmc_rescan() after switching back to higher clock.
This is not a fix.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Mon, Oct 03, 2005 at 03:02:52PM +0100, Russell King wrote:
> I'm not surprised. CMD2 is part way through the initialisation
> sequence, so no one should be sending a CMD7.
The command sequence in the initial card detection is:
CMD1 card send its operation conditions
CMD2 card sends its CID
CMD3(rca) Card is given relative call address. Card enters standby and
switches to push pull mode and won't respond to CMD1-3 anymore.
CMD2 Check for other cards. None responds. All cards have been
identified. CMD2 is sent many times.
CMD7(rca) The card is addressed with its RCA and enters transfer state.
The card is then accessed normally and everything works and also
ATP and Transcend cards work up to this.
Problems appear when mmc_detect_change() is called from switch_handler().
This happens when cover switch interrupt comes but the card has not been
removed. Old cards are checked with CMD13 and new cards if any are
detected:
CMD7(0) Deselect currently selected card. Its RCA remains the
same.
CMD1
CMD2 CMD2 sent many times, but no card replies.
CMD7(rca) The selected card should respond. ATP and Transcend
give illegal instruction instead and retries with CMD7
fail.
> After a CMD2, the next expected command is a CMD3 for MMC cards (maybe
> not SD cards).
Does this apply when threre are no new cards and no card replied to
CMD2?
Jarkko Lavinen