RCM3900 SD flash power down

Hi,

I'm looking to use an RCM3900 in a project, I just have one question
about powering down the SD (and I guess it could apply to the onboard
flash as well). I plan on using it to log data periodically, but the
system can be powered off at any time. Is it a problem if the system
gets turned off while the NAND flash is being written?

I don't care about the last chunk of data that's about to be written
(several bytes), but since the data is written in larger chunks than
that (512 bytes), is it possible that I'll corrupt that entire block
of data? If so, what are the possible solutions?

One that I was thinking about doing is using a supercap with a low
voltage drop schottky diode to hold up the power pin long enough for
it to finish a write. I think this would work, since the logic to
complete the write is inside the SD module, but this requires
modifying the Rabbit.

The other thing I was thinking is since I'll have the battery backed
SRAM would be to buffer the entire current 512 byte block to the RAM,
and write the entire block to SD at once, then verify, then erase the
RAM. If the power was turned off, the write would fail, but the SRAM
would still be holding the entire block, ready to write when power
came back up. The only thing I don't know about with this is that I
think SD has an auto erase before write if necessary, so how could I
be sure that it didn't first try to erase an entire 16K erase block?
I think this method would work for the on board NAND flash though,
since you need to explicitly use the erase command.

So, has anyone come up with any solutions to this in the past, or have
any input on it?

Thanks,
Pat
Start a New Thread

pdaderko wrote:
> Hi,
>
> I'm looking to use an RCM3900 in a project, I just have one question
> about powering down the SD (and I guess it could apply to the onboard
> flash as well). I plan on using it to log data periodically, but the
> system can be powered off at any time. Is it a problem if the system
> gets turned off while the NAND flash is being written?
>
> I don't care about the last chunk of data that's about to be written
> (several bytes), but since the data is written in larger chunks than
> that (512 bytes), is it possible that I'll corrupt that entire block
> of data? If so, what are the possible solutions?
>
> One that I was thinking about doing is using a supercap with a low
> voltage drop schottky diode to hold up the power pin long enough for
> it to finish a write. I think this would work, since the logic to
> complete the write is inside the SD module, but this requires
> modifying the Rabbit.
>
> The other thing I was thinking is since I'll have the battery backed
> SRAM would be to buffer the entire current 512 byte block to the RAM,
> and write the entire block to SD at once, then verify, then erase the
> RAM. If the power was turned off, the write would fail, but the SRAM
> would still be holding the entire block, ready to write when power
> came back up. The only thing I don't know about with this is that I
> think SD has an auto erase before write if necessary, so how could I
> be sure that it didn't first try to erase an entire 16K erase block?
> I think this method would work for the on board NAND flash though,
> since you need to explicitly use the erase command.
>
> So, has anyone come up with any solutions to this in the past, or have
> any input on it?
>

The ZW FAT librayr has a cache for the FAT and data. You can only
guarantee data is written by un-mounting the filesystem or flushing the
cache..

The NAND Flash uses 16k sectors, not 512.

For logging apps, you will need to open the file, write the data, close
the file then call fat_SyncPartition() to flush the cache. Not really a
good idea for the NAND Flash as both the directory and data sectors will
get written on each write.

Ideally, you would have a power-fail detect with enough run time to
un-mount the partition.

ZW basically assumes you have battery-backed RAM. It will flushed
incomplete writes on boot up. If you don't have battery-backed RAM, then
the data is lost and most likely the entire file will not be there as
the directory info is the last thing written.

SD/MMC does automatic sector rewrites so writng 512 bytes will read in
the full block (most likely 64k), modify the sector and then write the
block.

ZW's FAT lib is a pain. I would say, half of the users of my MMC driver
gave up and wrote directly to the MMC/SD card. They had too many
corruption issues with the lib; a power down with open files or loss of
battery-backed RAM would destroy the file system.

--
------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------
Rabbit libs: http://www.shdesigns.org/rabbit/
today's fortune
Anyone who imagines that all fruits ripen at the same time
as the strawberries, knows nothing about grapes.
-- Philippus Paracelsus
Start a New Thread

--- In r..., Scott Henion wrote:
>
> pdaderko wrote:
> > Hi,
> >
> > I'm looking to use an RCM3900 in a project, I just have one question
> > about powering down the SD (and I guess it could apply to the onboard
> > flash as well). I plan on using it to log data periodically, but the
> > system can be powered off at any time. Is it a problem if the system
> > gets turned off while the NAND flash is being written?
> >
> > I don't care about the last chunk of data that's about to be written
> > (several bytes), but since the data is written in larger chunks than
> > that (512 bytes), is it possible that I'll corrupt that entire block
> > of data? If so, what are the possible solutions?
> >
> > One that I was thinking about doing is using a supercap with a low
> > voltage drop schottky diode to hold up the power pin long enough for
> > it to finish a write. I think this would work, since the logic to
> > complete the write is inside the SD module, but this requires
> > modifying the Rabbit.
> >
> > The other thing I was thinking is since I'll have the battery backed
> > SRAM would be to buffer the entire current 512 byte block to the RAM,
> > and write the entire block to SD at once, then verify, then erase the
> > RAM. If the power was turned off, the write would fail, but the SRAM
> > would still be holding the entire block, ready to write when power
> > came back up. The only thing I don't know about with this is that I
> > think SD has an auto erase before write if necessary, so how could I
> > be sure that it didn't first try to erase an entire 16K erase block?
> > I think this method would work for the on board NAND flash though,
> > since you need to explicitly use the erase command.
> >
> > So, has anyone come up with any solutions to this in the past, or have
> > any input on it?
> >
>
> The ZW FAT librayr has a cache for the FAT and data. You can only
> guarantee data is written by un-mounting the filesystem or flushing the
> cache..
>
> The NAND Flash uses 16k sectors, not 512.
>
> For logging apps, you will need to open the file, write the data, close
> the file then call fat_SyncPartition() to flush the cache. Not really a
> good idea for the NAND Flash as both the directory and data sectors
will
> get written on each write.
>
> Ideally, you would have a power-fail detect with enough run time to
> un-mount the partition.
>
> ZW basically assumes you have battery-backed RAM. It will flushed
> incomplete writes on boot up. If you don't have battery-backed RAM,
then
> the data is lost and most likely the entire file will not be there as
> the directory info is the last thing written.
>
> SD/MMC does automatic sector rewrites so writng 512 bytes will read in
> the full block (most likely 64k), modify the sector and then write the
> block.
>
> ZW's FAT lib is a pain. I would say, half of the users of my MMC driver
> gave up and wrote directly to the MMC/SD card. They had too many
> corruption issues with the lib; a power down with open files or loss of
> battery-backed RAM would destroy the file system.
>
> --
> ------
> | Scott G. Henion| shenion@... |
> | Consultant | Stone Mountain, GA |
> | SHDesigns http://www.shdesigns.org |
> ------
> Rabbit libs: http://www.shdesigns.org/rabbit/
> today's fortune
> Anyone who imagines that all fruits ripen at the same time
> as the strawberries, knows nothing about grapes.
> -- Philippus Paracelsus
>

Thanks for the fast reply. I'm actually not planning on using the FAT
lib though... I'm just writing directly to the blocks (like the
nflash_log.c and sdflash_log.c examples), and erasing the entire flash
when I am done with the data. All logging is just appended, so I
don't want it to erase anything, except when I'm done with the log.

I don't have any need to remove the SD card, or read it in a PC (I
just want the log available for viewing/downloading from the
network)... it's main purposes are for more storage (although the 32MB
NAND on board should be enough) and also that it's easily replacable
rather than having to replace the entire Rabbit module if it fails.

Since I don't need to erase much, with the NAND flash, I was using
#define NFLASH_USEERASEBLOCKSIZE 0 to get 512 byte write blocks,
rather than the 16KB blocks. If it's much easier/more reliable, I may
end up just using the on board NAND flash rather than SD.

Thanks,
Pat
Start a New Thread