high density serial flash

Hi folks,

Can anyone recommend high density serial flash parts for embedded system code storage? I'm looking for at least 8Mbit, preferably 16 or even 32.

Nexflash aren't shipping yet, and 16mbit isn't expected until mid next year. Similarly SST is only up to 2 or 4mbit right now. I saw a mention on EE times of Taiwanese companies Mycomp and TMC, but could find no info on their serial flash devices.

For this application, we just need to store code/data that will be copied into RAM at boot time. Is there another technology that might be suitable in the densities I'm looking for?

Low pin count is the main priority.

I've also looked at NAND flash, which has a fairly low pin count, but am a bit put off by the complexity of implementing controller hardware and software that will only be in use at bootup.

Any suggestions?

Thanks,

John

Reply to
John Williams
Loading thread data ...

Take a look at ATMEL's Dataflash - currently up to 128Mbit (and going further apparently) They also offer Dataflash Cards (which are in the standard MMC format). They have a nice upgrade path from 1 Mbit up to the maximum - in both BGA and TSSOP packages.

We have used Dataflash to store an embbedded Linux distribution, and have even mapped the dataflash to the file system.

They use a SPI interface.

Reply to
Simon Berry

sorry - forgot to add the URL :

formatting link

Reply to
Simon Berry

Ah yes, that's the ticket! That's exactly what we'll be storing, uClinux kernel and filesystem images - in this case the kernel is running on a soft-core processor inside a Xilinx FPGA.

Thanks for that Simon,

Regards,

John

Reply to
John Williams

Just curious - what exactly is the complexity here? It's simple to develop a very easy proprietary filesystem running on NAND flash, particularly when your app is "write once, read many". Basically, just store your data linearly, and skip blocks that are marked bad.

Reply to
Lewin A.R.W. Edwards

ST has serial flash products in this range.

Reply to
Gary Reichlinger

Yes fair point - SPI-based serial flash would be nice because there are already SPI cores that I can use (processor is FPGA-based) - know any refs of app notes discussing the h/w interface between Nand flash and a microprocessor? Since it's just a start-up operation, I wonder if I could get away with just bitbanging over a GPIO-style interface... must look more closely at the data sheets.

Thanks,

John

Reply to
John Williams

The largest part listed on their website is 8Mbit - I'd need at least 2 of them, plus level translators since I'm interfacing with 2.5V IO.

Also does anyone have experience with the Atmel dataflash, I've had at least one opinion that they are unreliable and have a rather low write-cycle count (< 1000). Seems a shame, since they have the high densities that I'm looking for. Any comments?

Thanks,

John

Reply to
John Williams

My understanding is it is basically unlimited. From memory you just need to a block erase before any of the pages in that block reach 10k cycles. This is from memory, atmel has an app note on it somewhere.

Ralph

Reply to
Ralph Mason

Hi John,

You most certainly can do it with GPIOs; that's the way I did it first time round. I can give you some sample C code for the block-level access, if you like. But it's simple enough to deduce how to do it from the chip datasheet, nothing complicated there. The complexities lie in error correction and the fact that a FAT filesystem normally lives at the next level up.

Reply to
Lewin A.R.W. Edwards

I would be very interested to see some sample code for this. As you say, it can be inferred from the data sheets but at this early evaluation stage it would be very helpful to me.

As for file systems, it's not such a big deal for me... I could potentially partition the flash, use a boot block in a simple "raw" mode to boot, then once linux boots use the MTD Nand flash drivers with a proper filesys over the top.

Cheers,

John

Reply to
John Williams

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.