 |
 |
| View previous topic :: View next topic |
| Author |
Message |
EdWaugh
Joined: 07 Dec 2004
Posts: 127
Location: Southampton, UK
|
| MMC Erase and lock/unlock commands |
 Posted: Tue Oct 07, 2008 1:12 pm |
 |
|
Hi all,
I've been developing some PIC MMC drivers for a while now including my own filesystem that we use for data logging. Recently I wanted to up the data rate and have found an interesting problem. I am using the MMCs erase commands to erase the entire card as required however I am suspicious that it is not really erasing the card and rather just tagging sectors as erased. The reason for this is that as I write data to the card at a high rate I periodically get a much longer write time than is typical, around 10x as long. I think this is because I have just written into a new erase block and it is then performing the erase. Also the erase command, while reporting success only takes a few seconds, not as long as I would expect.
Does anyone have experience with the erase command and a possible solution to force the mmc to properly wipe the card when I format it?
This has lead me to the Force Erase command... You can use this when the card has been locked and the password is unknown, it wipes the card and unlocks it so this must be a complete clean of the whole card (takes up to 3 minutes according to the spec). However the card needs to be locked first so I have implemented the lock/unlock commands and (as is typical) have managed to lock the card successfully but not to unlock it again. Both commands give me the same trouble tho, after they have executed (giving expected responses) the card becomes unresponsive to further commands including cmd1 and cmd13. I can lock the card because this occurs on a power cycle as I have successfully set the password, I can't unlock it because I need to follow the unlock command with the clear password command before a power cycle.
I hope that makes sense. I have put my code for locking the card below in the hope that I have just misinterpreted the command format. It is pretty heavily commented/debugging output at the moment so hopefully it is fairly understandable.
Any suggestions would be very welcome as always.
thanks
ed
| Code: |
case MMC_LUL_LOCK_CARD:
fprintf(MMC_STRM,"Lock card\r");
mmc_set_block_length(3);
// Lock the card so force erase command will work
// Also need to set the password, use a single byte set to 0xAA
SS_ON; // set SS = 0 (on)
cmd.ui8_cmd = MMC_CMD42_LOCK_UNLOCK;
cmd.ui32_arg = 0x00; // There is no address argument
mmc_write_cmd(&cmd, MMC_CMD_NO_CRC);
if(mmc_get_response(R1_RESPONSE))
{
fprintf(MMC_STRM, "Didn't get r1 response to lock unlock\r");
}
spi_write(MMC_SINGLEBLOCK_DATA_TOKEN);
spi_write(0x01); // Set password bit
spi_write(0x01); // New password length
spi_write(0xAA); // New password data
spi_write(0xFF); // 16-bit dummy CRC
spi_write(0xFF);
if(mmc_get_data_token(MMC_WRITE_DATA_TOKEN))
{
fprintf(MMC_STRM, "Didn't get writedata token to set password\r");
}
fprintf(MMC_STRM, "Got writedata token to set password\r");
ui16_timeout = 0;
do
{
ui8_data = spi_read(0xFF);
ui16_timeout++;
}while((ui8_data == 0X00) && (ui16_timeout < 65535)); // Busy signal is low (0x00)
if(ui16_timeout == 65535)
{
#ifdef MMC_FULL_DEBUG fprintf(MMC_STRM, "Timeout waiting for not busy\r"); #endif
SS_OFF;
spi_write(0xFF);
return 1;
}
#ifdef MMC_FULL_DEBUG fprintf(MMC_STRM, "Got not busy response to write block at %lu\r", ui16_timeout); #endif
SS_OFF;
spi_write(0xFF);
break;
|
|
|
 |
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Tue Oct 07, 2008 2:53 pm |
|
|
Two comments:
1. I can't see from the MMC spec (4.4.10 Card Lock/Unlock Operation - Forcing Erase), that it's required to lock the card before issuing a forced erase. I understand from the spec, that the command should be performed unconditionally.
2. I understand from the description of the erase command (4.4.8 Erase, CMD35, 36, 38), that the command is expected to perform a physical erase:
| Quote: | | The content of an explicitly erased memory range shall be 0. |
I didn't check with a specific card. It also may be the case, that existing products are not exactly compliant to the MMC spec. |
|
|
EdWaugh
Joined: 07 Dec 2004
Posts: 127
Location: Southampton, UK
|
|
| Posted: Tue Oct 07, 2008 4:45 pm |
|
|
Hey FvM,
Thanks for your response, I have version 4.3 of the spec and on page 45 it says:
| Quote: |
An attempt to force erase on an unlocked card will fail and LOCK_UNLOCK_FAILED error bit will be
set in the status register.
|
My understanding of the erase command is also that it should perform physical erase but this is not necessarily how it has to work internally, simply tagging which blocks are erased and then dealing with them as you need to is quite efficient if you have big RAM buffers and/or non-continuous data. Certainly after using the erase command I can read the blocks and see they are blank, but it is the extended delay that makes me think that it must be doing something else...
thanks
ed |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Wed Oct 08, 2008 12:23 am |
|
|
Hello,
I didn't read this statement regarding forced erase in 4.3, it's unfortunately not repeated in the detailed command description.
Regarding the regular erase function. Yes, I can imagine, that a card only does a remapping instead of a physical erase. But I didn't see a possible purpose, cause the the erase command works on complete erase units only. So if you logically erase a block of memory, why not phsysically erasing it immediately, it has to be erased anyway before further usage. It could be however, that erase is performed as a background operation, started at the erase command and acknowledged immediately, but finished later. Cause these operations are encapsulated, it may be difficult to find out the real behaviour.
Regards,
Frank |
|
|
EdWaugh
Joined: 07 Dec 2004
Posts: 127
Location: Southampton, UK
|
|
| Posted: Wed Oct 08, 2008 1:19 am |
|
|
Hi Frank,
Yes I think you're correct, all I can say is what I have observered by monitoring the time taken to write a new block, it does occur on specific boundaries, I will try and locate them and report back, it may well be the erase block boundaries.
I don't suppose you can see anything wrong with my technique for operating the lock/unlock command? I suspect it is something I am doing routinely wrong but normally get away with... I could post my erase function so you could have a look if you like.
thanks
ed |
|
|
FvM
Joined: 27 Aug 2008
Posts: 2337
Location: Germany
|
|
| Posted: Wed Oct 08, 2008 11:59 am |
|
|
Hello ed,
I must confess, that I never used the forced erase command and possibly won't detect an error. But the general method, as you described it, sounds plausible to me. Also I didn't yet use MMC/SDcard in PIC projects, only with X86 and ATmega up to now. But the present PIC projects have storage options, that would imply memory cards.
Regards,
Frank |
|
|
EdWaugh
Joined: 07 Dec 2004
Posts: 127
Location: Southampton, UK
|
|
| Posted: Thu Oct 09, 2008 3:53 am |
|
|
Hi Frank,
I was having a think about it and was wondering if anyone had the MMC spec document v4.2. I'm working from a combination of v4.3 (where spi is removed) and v3.1 for an SD card (doesn't support lock/unlock). It is possible there is a subtly different syntax for this command over SPI that I am missing out on.
Any further suggestions would be very welcome.
cheers
ed |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
