Forums

Need a replacement for 4MB serial flash from ATMEL

Started by dhan...@solus.co.in October 14, 2010
Hi to all,

We are facing an issue nothing technical but affecting the development task. That is we have two serial Flashes on our product interfaced using SPI and SSP, one is used to store the firmware using file system another stores a raw memory which is the user settings and some editable data.

Then we have another SD card to store firmware using file system as an alternative option.

We are not able to produce no of boards as many as we want because ATMEL 4MB SF is under huge demand from many places. we are one of them.

We found a 4MB SF, that was SST. but writing in that flash needs the chip should be erase state, means cant edit the page without erasing that particular page.

So is there any alternative to get rid of ATMEL and use that as permanent solution? and PCB's are made so pin compatibility also as big issue.

Another doubt is that can we create partial filesystem on SD card and can the remaining memory be used as a raw memory?

So that i can store my firmware using file system and i can use that file system for some other purpose also.
And in raw memory i can write my data without much worry...

Can anyone please give some clue to come out of this issue?
and

An Engineer's Guide to the LPC2100 Series

We have just done this for exactly the same reason

We are using a micro-SD card in SPI mode to replace the Atmel Flash.
I am just using the whole thing as raw memory, but if you have control of the filesystem you could split it.

Getting the micro-SD card initialised is not a trivial task. Writing can be a lot slower than serial flash. Also they are all slightly different, the "standard" is not very standard.

On the other hand you suddenly have 2GB of flash rather than 4MB!

--
Tim Mitchell

On Thu, Oct 14, 2010 at 5:20 PM, wrote:

> Hi to all,
>
> We are facing an issue nothing technical but affecting the development
> task. That is we have two serial Flashes on our product interfaced using SPI
> and SSP, one is used to store the firmware using file system another stores
> a raw memory which is the user settings and some editable data.
>
> Then we have another SD card to store firmware using file system as an
> alternative option.
>
> We are not able to produce no of boards as many as we want because ATMEL
> 4MB SF is under huge demand from many places. we are one of them.
>
> We found a 4MB SF, that was SST. but writing in that flash needs the chip
> should be erase state, means cant edit the page without erasing that
> particular page.
>
> So is there any alternative to get rid of ATMEL and use that as permanent
> solution? and PCB's are made so pin compatibility also as big issue.
>
> Another doubt is that can we create partial filesystem on SD card and can
> the remaining memory be used as a raw memory?
>
> So that i can store my firmware using file system and i can use that file
> system for some other purpose also.
> And in raw memory i can write my data without much worry...
>
> Can anyone please give some clue to come out of this issue?
> and
Check this out http://semicon.sanyo.com/en/memory/list.php?c2=1, it think
they have up to 1MB but not 4MB. Unlike the atmel parts these are NOR flash
but they do offer 256 byte page writes
--
Warm regards
Ashwin
NGX Technologies Pvt. Ltd.
On Thu, 14 Oct 2010 07:50:25 -0400, you wrote:

>Hi to all,
>
>We are facing an issue nothing technical but affecting the development task. That is we have two serial Flashes on our product interfaced using SPI and SSP, one is used to store the firmware using file system another stores a raw memory which is the user settings and some editable data.
>
>Then we have another SD card to store firmware using file system as an alternative option.
>
>We are not able to produce no of boards as many as we want because ATMEL 4MB SF is under huge demand from many places. we are one of them.
>
>We found a 4MB SF, that was SST. but writing in that flash needs the chip should be erase state, means cant edit the page without erasing that particular page.
>
>So is there any alternative to get rid of ATMEL and use that as permanent solution? and PCB's are made so pin compatibility also as big issue.
>
>Another doubt is that can we create partial filesystem on SD card and can the remaining memory be used as a raw memory?
>
>So that i can store my firmware using file system and i can use that file system for some other purpose also.
>And in raw memory i can write my data without much worry...
>
>Can anyone please give some clue to come out of this issue?
>and

Almost all SPI flash chips need erase before write - if you can set your system up to deal with this
it will give you a wide range of possible chips, e.g. doing a read-erase-write to write partial
erase blocks.
Amic are the cheapest I've found.
Note there are slight differences between makes, e.g. SST doesn't have page write (WTF?), Atmel
needs a status register write before writes can be enabled, and also erase granularity varies
between manufacturers.

Part numbers would be helpful

DaveS

On Thu, Oct 14, 2010 at 4:50 AM, wrote:

> Hi to all,
>
> We are facing an issue nothing technical but affecting the development
> task. That is we have two serial Flashes on our product interfaced using SPI
> and SSP, one is used to store the firmware using file system another stores
> a raw memory which is the user settings and some editable data.
>
> Then we have another SD card to store firmware using file system as an
> alternative option.
>
> We are not able to produce no of boards as many as we want because ATMEL
> 4MB SF is under huge demand from many places. we are one of them.
>
> We found a 4MB SF, that was SST. but writing in that flash needs the chip
> should be erase state, means cant edit the page without erasing that
> particular page.
>
> So is there any alternative to get rid of ATMEL and use that as permanent
> solution? and PCB's are made so pin compatibility also as big issue.
>
> Another doubt is that can we create partial filesystem on SD card and can
> the remaining memory be used as a raw memory?
>
> So that i can store my firmware using file system and i can use that file
> system for some other purpose also.
> And in raw memory i can write my data without much worry...
>
> Can anyone please give some clue to come out of this issue?
> and
>
>
Thanks to all,

None of the remaining serial Flashes are nither pin compatible nor available
in market. and most of them for code storage. So nothing different from SST.
I think i am correct.

So one thing i can do is, implementing Chan's FATFs will be a solution.

In that i may have to try implementing file system and raw memory access.
Tell me if there is any big challenge in that..

Right now we are using AT45DB321D (4MB Serial Flash) and 2 GB micro SD
card..

Any more suggestions??

On Thu, Oct 14, 2010 at 11:18 PM, David Smead wrote:

>
> Part numbers would be helpful
>
> DaveS
>
> On Thu, Oct 14, 2010 at 4:50 AM, wrote:
>
>> Hi to all,
>>
>> We are facing an issue nothing technical but affecting the development
>> task. That is we have two serial Flashes on our product interfaced using SPI
>> and SSP, one is used to store the firmware using file system another stores
>> a raw memory which is the user settings and some editable data.
>>
>> Then we have another SD card to store firmware using file system as an
>> alternative option.
>>
>> We are not able to produce no of boards as many as we want because ATMEL
>> 4MB SF is under huge demand from many places. we are one of them.
>>
>> We found a 4MB SF, that was SST. but writing in that flash needs the chip
>> should be erase state, means cant edit the page without erasing that
>> particular page.
>>
>> So is there any alternative to get rid of ATMEL and use that as permanent
>> solution? and PCB's are made so pin compatibility also as big issue.
>>
>> Another doubt is that can we create partial filesystem on SD card and can
>> the remaining memory be used as a raw memory?
>>
>> So that i can store my firmware using file system and i can use that file
>> system for some other purpose also.
>> And in raw memory i can write my data without much worry...
>>
>> Can anyone please give some clue to come out of this issue?
>> and
>>
>

--
Thanks And Regards

--
Dhanaraj S
Embedded development,
Solus Security Systems Pvt. Ltd.
Mob: +919739075574

Email: d...@solus.co.in | Web: www.solus.co.in
User programmable parameters can be stored in FRAM, which has unlimited
write cycles. Yes,
it's more expensive per bit, but with high speed R/W and no wear out factor,
it's a reasonable option.

See www.ramtron.com

DaveS

On Thu, Oct 14, 2010 at 10:01 PM, Dhanaraj S wrote:

> Thanks to all,
>
> None of the remaining serial Flashes are nither pin compatible nor
> available in market. and most of them for code storage. So nothing different
> from SST. I think i am correct.
>
> So one thing i can do is, implementing Chan's FATFs will be a solution.
>
> In that i may have to try implementing file system and raw memory access.
> Tell me if there is any big challenge in that..
>
> Right now we are using AT45DB321D (4MB Serial Flash) and 2 GB micro SD
> card..
>
> Any more suggestions??
>
> On Thu, Oct 14, 2010 at 11:18 PM, David Smead wrote:
>
>>
>> Part numbers would be helpful
>>
>> DaveS
>>
>> On Thu, Oct 14, 2010 at 4:50 AM, wrote:
>>
>>>
>>>
>>> Hi to all,
>>>
>>> We are facing an issue nothing technical but affecting the development
>>> task. That is we have two serial Flashes on our product interfaced using SPI
>>> and SSP, one is used to store the firmware using file system another stores
>>> a raw memory which is the user settings and some editable data.
>>>
>>> Then we have another SD card to store firmware using file system as an
>>> alternative option.
>>>
>>> We are not able to produce no of boards as many as we want because ATMEL
>>> 4MB SF is under huge demand from many places. we are one of them.
>>>
>>> We found a 4MB SF, that was SST. but writing in that flash needs the chip
>>> should be erase state, means cant edit the page without erasing that
>>> particular page.
>>>
>>> So is there any alternative to get rid of ATMEL and use that as permanent
>>> solution? and PCB's are made so pin compatibility also as big issue.
>>>
>>> Another doubt is that can we create partial filesystem on SD card and can
>>> the remaining memory be used as a raw memory?
>>>
>>> So that i can store my firmware using file system and i can use that file
>>> system for some other purpose also.
>>> And in raw memory i can write my data without much worry...
>>>
>>> Can anyone please give some clue to come out of this issue?
>>> and
>>>
> --
> Thanks And Regards
>
> --
> Dhanaraj S
> Embedded development,
> Solus Security Systems Pvt. Ltd.
> Mob: +919739075574
>
> Email: d...@solus.co.in | Web: www.solus.co.in
>
>
>
I Have with me a stock of  2 k pcs of SST25VF016BSST25VF016B-50-4C-S2AF-T
Please contact me if you find it suitable
MohitMobile :- 919216592131 India

--- On Fri, 10/15/10, Dhanaraj S wrote:

From: Dhanaraj S
Subject: Re: [lpc2000] Need a replacement for 4MB serial flash from ATMEL
To: l...
Date: Friday, October 15, 2010, 10:31 AM

 

Thanks to all,

None of the remaining serial Flashes are nither pin compatible nor available in market. and most of them for code storage. So nothing different from SST. I think i am correct.

So one thing i can do is, implementing Chan's FATFs will be a solution.
In that i may have to try implementing file system and raw memory access.  Tell me if there is any big challenge in that..

Right now we are using AT45DB321D (4MB Serial Flash) and 2 GB micro SD card..

Any more suggestions??
On Thu, Oct 14, 2010 at 11:18 PM, David Smead wrote:

 

Part numbers would be helpful
DaveS
On Thu, Oct 14, 2010 at 4:50 AM, wrote:

 

Hi to all,

We are facing an issue nothing technical but affecting the development task. That is we have two serial Flashes on our product interfaced using SPI and SSP, one is used to store the firmware using file system another stores a raw memory which is the user settings and some editable data.

Then we have another SD card to store firmware using file system as an alternative option.

We are not able to produce no of boards as many as we want because ATMEL 4MB SF is under huge demand from many places. we are one of them.

We found a 4MB SF, that was SST. but writing in that flash needs the chip should be erase state, means cant edit the page without erasing that particular page.

So is there any alternative to get rid of ATMEL and use that as permanent solution? and PCB's are made so pin compatibility also as big issue.

Another doubt is that can we create partial filesystem on SD card and can the remaining memory be used as a raw memory?

So that i can store my firmware using file system and i can use that file system for some other purpose also.

And in raw memory i can write my data without much worry...

Can anyone please give some clue to come out of this issue?

and

--
Thanks And Regards

--
Dhanaraj S
Embedded development,
Solus Security Systems Pvt. Ltd. 
Mob: +919739075574

Email: d...@solus.co.in |  Web: www.solus.co.in
Because of the non-availablity of Atmel flash, XMOS now supports the
Winbond W25X40BV for use with their chips. I bought several from
Digi-Key recently.

Leon
--
Leon Heller
G1HSM
On 10/15/2010 3:10 AM, David Smead wrote:
> User programmable parameters can be stored in FRAM, which has unlimited
> write cycles. Yes,
> it's more expensive per bit, but with high speed R/W and no wear out factor,
> it's a reasonable option.

That's my preferred solution as well. Not only is fast nice in its own
right (no waiting for write commands to finish) it dramatically reduces
the window during which the memory is vulnerable to disturbances that
will mess up it's data store.

The no wear out makes implementing data logs and counters a lot easier
and more effective as well.

Robert

--
http://www.aeolusdevelopment.com/

From the Divided by a Common Language File (Edited to protect the guilty)
ME - "I'd like to get Price and delivery for connector Part # XXXXX"
Dist./Rep - "$X.XX Lead time 37 days"
ME - "Anything we can do about lead time? 37 days seems a bit high."
Dist./Rep - "that is the lead time given because our stock is live....
we currently have stock."