SD Sporadic Write Delay

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey all,

So I have run into an issue which might possibly be simply a lack of knowledge about SD Hardware operation. Essentially I am interfacing to an SD card over SPI using an ATXMEGA256A3B. Currently I am writing raw data to the card with a multiple block write call, using blocks of 16 sectors. The call itself is working perfectly fine, it just seems that at random intervals there are 100+ ms delays to write to the SD card, an example is shown in the image included as an attachment. This image is a snapshot of the O-Scope which is currently measuring SD multiple block write call executions, where the clock is representative of a 16 block write for each high/low logic state (~600 KB/s).

I am curious if anyone has any insight into what the large delay is during this transaction, this delay occurs roughly every 3-6 seconds of transfer (it seems to be slightly sporadic, sometimes having two delays closely together).

Furthermore I'm also curious if anyone has some suggestions to further pump up the data throughput for this SD Card. Currently I am using a SPI interface at 16 MHz with multiple block write executions (16 blocks per write). Any ideas what might speed it up even more?

Thanks in advance,

Josh

P.S. The SD card I am using is a Patriot 4GB micro SDHC card, class 10.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Apparently this is perfectly normal for an SD card in SPI mode.
You may be able to significantly reduce this delay by pre-erasing the sectors before writing.

I'm just about to try this on an audio recording project I'm working on. I'm only getting 20ms (max) delays, but at a 16khz sampling rate, I need a buffer of 320 bytes to cover it!

CMD32, CMD33 and CMD38 look to be the commands to use to pre-erase sectors.

[edit: I'm using an old unbranded 32Mb SD card - might smaller cards be faster?]

Nigel Batten
www.batsocks.co.uk

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

At a guess I'd say it is the card doing an internal bad block remap. Remember that Nand arrays will have sectors that fail. Writing is very like what happens on a hard drive. The data is committed to a sector then verified. If it fails verification (well on an HDD anyway) there are multiple attempts to re-write it (in the HDD case there's usually 64 attempts with the head slightly aligned to either side of the track and also after recalibrations - Nand obviously has no equivalent but I imagine there could be more than one re-write attempt, some possibly with erase cycles). When the writing firmware concludes that it cannot write the sector it allocates a sector from the "spare pool" (which itself might take multiple retries if it too has faults). It then adds that sector to it's remap table so that when subsequent read/writes are attempted to sector M it is actually done to sector N in the remap pool.

I'm not sure if SD/MMC have such a thing as a datasheet or whether it's just treated like a commodity product and the internal operation is a "black box" but such technical data might explain min/max sector write timing and even what the remap strategy was.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the quick responses,

Condemned, I will definitely try out pre-erasing sectors in advance. What sort of range do you think I should attempt to pre-erase (perhaps 25% of the card or more?). Currently my multiple block write function call issues the set_erase_wr_block commands (perhaps wrong wording there) which is CMD55-APPCMD23 which specifies the amount of blocks to pre-erase before each write, but that is only write specific, not clearing large sections of the card.

Clawson, first of all, love the signature... would have been nice to see that when I was first playing around with AVRs (had a fun run in with not setting making a flag in an ISR volatile). Yes I believe that the internal workings of the cards are proprietary information for the development company, all I really have is the good ol' Physical Layer specification document, which of course only covers interfacing, and doesn't seem to have much information on these kinds of write delays, although it does hint towards some kind of possible write issues.

Currently for my application I am essentially reading in streaming video data from a CMOS camera (at very low resolutions, as the data is coming in at 15 FPS @ 12MHz bursts) which totals to ~360 KB/s. I am using an CPLD to handle the actual data reading as the XMEGA doesn't have quick enough edge detection to handle the 12MHz data bursts. However I should have the write speeds to tackle the data rates no problem, except that during these huge write delays I will certainly overflow the buffers available on the XMEGA (we only have about 16KB of buffer available).

Yes I realize that this certainly isn't the optimum setup for handling this kind of data throughput, but this is an education oriented project and we are all learning... in a very frustrating way sometimes, but none-the-less learning.

Does anyone perhaps have suggestions on pushing the write speeds even higher? So that if we did find a way to buffer the write delays, rather than simply disregarding that data, we could clear the buffer quick enough to be ready for the next write delay?

Thanks in advance,

Josh

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Does anyone perhaps have suggestions on pushing the write speeds even higher?

Use 4 bit mode for the SD/MMC (except you have to license this). Use two cards and alternate the writes (keep adding cards until you can cope with the bandwidth). If data is "bursts" then add a large SRAM to the design - buffer the data in the short-term then write at leisure between the "bursts" (though this kind of depends how long the bursts are and how much time there is in between).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clawson, currently we are using a CPLD to read the data bursts and storing them in a FIFO hardware buffer that we can clock to the MCU at our leisure, which should work out great. As it stands, 15 FPS on the camera will give the data out such that we have 96 bytes of data, followed by a ~190us delay before the next 96 byte burst. It currently takes the MCU 24us to clock the data from the FIFO buffer to the MCU so the rest of the time is purely for writing and should work out just fine (approximately 600 KB/s write speeds and only 360 KB/s incoming data). However when we get those write delays we will simply have to lose the data as it would require approximately at 60 KB or larger buffer to hold all the images that get clocked in during that time.

My wonder is what exactly these write delays are (once again refer to the above O-Scope image), is it possible they are write block gaps where the SD card is switching between different blocks of physical memory? I tried pre-erasing almost the entire card (75% or 3GB of it) and we still got the write delays so they must not be a pre-erase delay. The Physical Layer specifies that there may be delays up to 250ms during write block gaps, anyone have any insight into this? It really would be nice if the manufacturers of the card would give some spec sheets or something.

- Josh

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would second the idea to move to 4-bit mode, although I understand this will be a big change for you. The problem is that SPI is largely a legacy mode - the card manufacturers have to support it, but they don't have to support it well. 4 bit mode on the other hand they must support well, to be able to achieve their stated performance (such as the class 10 card you have).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, that is unfortunate that the manufacturer's don't have to meet their data throughput specifications on both interfaces, but I can understand why. So moving over to a 4-wire interface would guarantee that we would see the advertised throughputs, or at least be capable of reaching them? I guess the only other option if we don't have the time/opportunity for the hardware switch to 4-wire would be to find an SD card with a faster SPI interface... is it perhaps possible to identify the data throughputs of SD cards based on their SPI interface modes? That would be handy.

Thanks,

Josh

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On the whole (as with most things electronic) you can probably rely on Moores Law meaning that more modern = faster. (Increase in capacity is likely because of reduction in fab geometry). So I'd guess that a 4GB or 16GB SDHC (or even larger) is likely to have the best data rates on all interfaces.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

josh_t wrote:
Well, that is unfortunate that the manufacturer's don't have to meet their data throughput specifications on both interfaces, but I can understand why. So moving over to a 4-wire interface would guarantee that we would see the advertised throughputs, or at least be capable of reaching them? I guess the only other option if we don't have the time/opportunity for the hardware switch to 4-wire would be to find an SD card with a faster SPI interface... is it perhaps possible to identify the data throughputs of SD cards based on their SPI interface modes? That would be handy.

Thanks,

Josh

Nothing that I'm aware of. We had a similar problem with a previous project, and bought a handful of different cards to benchmark over the SPI interface. There were huge variations between cards. Problem was, the cards kept changing, so we could never buy the same card for more than a few months.

Design we're working on now is using the SD card in 4-bit mode (using an STM32 though, not an AVR, because the STM32 has a 4-bit SDIO interface built into it) and we're seeing far better, and more consistent, performance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, thanks for all the help everyone.

I have a good idea of where I need to go from here, and I will definitely be looking into 4-bit interfacing to see if we have the time/hardware space to put this in. All in all we should be able to manage 15 FPS on the camera at the current speeds, it would just be nice to be able to reach our full goal of 30 FPS.

Appreciate all the responses,

- Josh

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW in the past when we've wanted high performance Nand memory on cards we've used CompactFlash but I guess that'd be quite an undertaking on an AVR as you'd have to implement an IDE interface.

[BTW, you may have noticed that top end digital SLRs use CF rather than SD/MMC or any other alternative - this is so they can capture realtime "raw" images that journalists and professionals want to use]