[ECOS] cyg_flash_program_mask

[ECOS] cyg_flash_program_mask

[Tom Schouten]

Hi folks,

It seems that many Flash devices expose separate "program" and "erase"
operations.  It also seems fairly common to represent an erased bit as
"1" and a programmed bit as "0".  In this view "program" can only
perform a 1->0 transition and "erase" resets bits back to 1.  So a
Flash chip's "program" operation is logically an "and-mask" operation.

Since the erase operation is one that ages the chip, it makes sense in
some applications to use multiple overlaying "and-mask" operations to
incrementally write to data units that are smaller than the smallest
erase unit.

Is there any interest to add support for this behaviour to the eCos
API?

If I understand correctly, the cyg_flash_program() operation erases
before program such that the resulting bit pattern in the Flash always
represents the input bit pattern exactly, instead of being the result
of an "and-mask" operation.

A single extra API function could be enough:

int cyg_flash_program_mask(cyg_flashaddr_t flash_base,
                            void *ram_base, size_t len,
                            cyg_flashaddr_t *err_address);

Cheers,

Tom


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] cyg_flash_program_mask

[Andrew Lunn]

> If I understand correctly, the cyg_flash_program() operation erases
> before program such that the resulting bit pattern in the Flash always
> represents the input bit pattern exactly, instead of being the result
> of an "and-mask" operation.

I think you are wrong. Take a look at the code. cyg_flash_program()
does not call any erase functions.

I've done exactly what you want to do in the past. I implemented an
log of panic messages which just appended to the end of the current
log. No API change was needed.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] cyg_flash_program_mask

[Tom Schouten]

On 02/15/2011 11:45 AM, Andrew Lunn wrote:
>> If I understand correctly, the cyg_flash_program() operation erases
>> before program such that the resulting bit pattern in the Flash always
>> represents the input bit pattern exactly, instead of being the result
>> of an "and-mask" operation.
>>      
> I think you are wrong. Take a look at the code. cyg_flash_program()
> does not call any erase functions.
>
> I've done exactly what you want to do in the past. I implemented an
> log of panic messages which just appended to the end of the current
> log. No API change was needed.
>    


I found the other behaviour in the atmel dataflash implementation
(current CVS tree).

In 
packages/devs/flash/atmel/dataflash/current/src/devs_flash_atmel_dataflash_flash_dev_funs.c:
In function df_flash_program()
cyg_dataflash_program_buf(&priv->dev, 1, page, true)

In 
packages/devs/flash/atmel/dataflash/current/src/devs_flash_atmel_dataflash.c:

int
cyg_dataflash_program_buf(cyg_dataflash_device_t *dev,
                           cyg_uint8               buf_num,
                           cyg_uint32              page_num,
                           cyg_bool                erase)

Hence for atmel dataflash the "erase" is always true.

So which one should it be?
 From the eCos documentation it isn't really clear what the correct 
behaviour should be.
To erase or not to erase?



>       Andrew
>
>    
Tom



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] cyg_flash_program_mask

[Andrew Lunn]

On Tue, Feb 15, 2011 at 12:18:14PM -0500, Tom Schouten wrote:
> On 02/15/2011 11:45 AM, Andrew Lunn wrote:
> >>If I understand correctly, the cyg_flash_program() operation erases
> >>before program such that the resulting bit pattern in the Flash always
> >>represents the input bit pattern exactly, instead of being the result
> >>of an "and-mask" operation.
> >I think you are wrong. Take a look at the code. cyg_flash_program()
> >does not call any erase functions.
> >
> >I've done exactly what you want to do in the past. I implemented an
> >log of panic messages which just appended to the end of the current
> >log. No API change was needed.
> 
> 
> I found the other behaviour in the atmel dataflash implementation
> (current CVS tree).
> 
> In packages/devs/flash/atmel/dataflash/current/src/devs_flash_atmel_dataflash_flash_dev_funs.c:
> In function df_flash_program()
> cyg_dataflash_program_buf(&priv->dev, 1, page, true)
> 
> In packages/devs/flash/atmel/dataflash/current/src/devs_flash_atmel_dataflash.c:
> 
> int
> cyg_dataflash_program_buf(cyg_dataflash_device_t *dev,
>                           cyg_uint8               buf_num,
>                           cyg_uint32              page_num,
>                           cyg_bool                erase)
> 
> Hence for atmel dataflash the "erase" is always true.

Interesting.  

All the NAND flash drivers i know don't erase when programming.  So i
would say the data flash does not follow the normal convention.

I would say adding a new API call just for dataflash is wrong.
However, changing the behaviour could also cause problems for some
people. So i would suggest adding a CDL option to control if data
flash should erase or not when programming.

      Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] cyg_flash_program_mask

[Tom Schouten]

On 02/15/2011 12:28 PM, Andrew Lunn wrote:
> On Tue, Feb 15, 2011 at 12:18:14PM -0500, Tom Schouten wrote:
>    
>> On 02/15/2011 11:45 AM, Andrew Lunn wrote:
>>      
>>>> If I understand correctly, the cyg_flash_program() operation erases
>>>> before program such that the resulting bit pattern in the Flash always
>>>> represents the input bit pattern exactly, instead of being the result
>>>> of an "and-mask" operation.
>>>>          
>>> I think you are wrong. Take a look at the code. cyg_flash_program()
>>> does not call any erase functions.
>>>
>>> I've done exactly what you want to do in the past. I implemented an
>>> log of panic messages which just appended to the end of the current
>>> log. No API change was needed.
>>>        
>>
>> I found the other behaviour in the atmel dataflash implementation
>> (current CVS tree).
>>
>> In packages/devs/flash/atmel/dataflash/current/src/devs_flash_atmel_dataflash_flash_dev_funs.c:
>> In function df_flash_program()
>> cyg_dataflash_program_buf(&priv->dev, 1, page, true)
>>
>> In packages/devs/flash/atmel/dataflash/current/src/devs_flash_atmel_dataflash.c:
>>
>> int
>> cyg_dataflash_program_buf(cyg_dataflash_device_t *dev,
>>                            cyg_uint8               buf_num,
>>                            cyg_uint32              page_num,
>>                            cyg_bool                erase)
>>
>> Hence for atmel dataflash the "erase" is always true.
>>      
> Interesting.
>
> All the NAND flash drivers i know don't erase when programming.  So i
> would say the data flash does not follow the normal convention.
>
> I would say adding a new API call just for dataflash is wrong.
> However, changing the behaviour could also cause problems for some
> people. So i would suggest adding a CDL option to control if data
> flash should erase or not when programming.
>
Indeed, if not erasing is the appropriate program behaviour then there 
is no API change necessary.
However it does seem appropriate to make this convention explicit so 
future implementations of the flash API can make the right decision.
A CDL option does seem best for making it backwards "bug-compatible" for 
the implementations that do not follow convention.

Thanks for your answer, Andrew.

Cheers,
Tom



>        Andrew
>
>    


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] cyg_flash_program_mask

[Andrew Dyer]

On Tue, Feb 15, 2011 at 10:07, Tom Schouten <tom@zwizwa.be> wrote:
> Hi folks,
>
> It seems that many Flash devices expose separate "program" and "erase"
> operations.  It also seems fairly common to represent an erased bit as
> "1" and a programmed bit as "0".  In this view "program" can only
> perform a 1->0 transition and "erase" resets bits back to 1.  So a
> Flash chip's "program" operation is logically an "and-mask" operation.
>
> Since the erase operation is one that ages the chip, it makes sense in
> some applications to use multiple overlaying "and-mask" operations to
> incrementally write to data units that are smaller than the smallest
> erase unit.
>
> Is there any interest to add support for this behaviour to the eCos
> API?
>
> If I understand correctly, the cyg_flash_program() operation erases
> before program such that the resulting bit pattern in the Flash always
> represents the input bit pattern exactly, instead of being the result
> of an "and-mask" operation.
>
> A single extra API function could be enough:
>
> int cyg_flash_program_mask(cyg_flashaddr_t flash_base,
>                           void *ram_base, size_t len,
>                           cyg_flashaddr_t *err_address);
>

You have to be very careful doing this.  At least some NAND flash
parts have restrictions on how many 'partial page program' cycles you
can do.  For the part I am using, the restriction is 4 for normal
memory pages, and 8 for the one time programmable area.

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] cyg_flash_program_mask

[Andrew Lunn]

On Tue, Feb 15, 2011 at 12:47:49PM -0600, Andrew Dyer wrote:
> You have to be very careful doing this.  At least some NAND flash
> parts have restrictions on how many 'partial page program' cycles you
> can do.  For the part I am using, the restriction is 4 for normal
> memory pages, and 8 for the one time programmable area.

Hi Andrew

So for the none one-time blocks, after 4 partial writes you need to do
an erase, before you can do more partial rights? Or are you saying
only 4 ever?

What part is this?

     Thanks
	Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] cyg_flash_program_mask

[Andrew Dyer]

On Tue, Feb 15, 2011 at 23:46, Andrew Lunn <andrew@lunn.ch> wrote:
> On Tue, Feb 15, 2011 at 12:47:49PM -0600, Andrew Dyer wrote:
>> You have to be very careful doing this.  At least some NAND flash
>> parts have restrictions on how many 'partial page program' cycles you
>> can do.  For the part I am using, the restriction is 4 for normal
>> memory pages, and 8 for the one time programmable area.
>
> Hi Andrew
>
> So for the none one-time blocks, after 4 partial writes you need to do
> an erase, before you can do more partial rights? Or are you saying
> only 4 ever?
>
> What part is this?

This is a recent Micron 2Gb large page NAND (I don't have the
datasheet handy, but I believe it was the M60A generation).  The
limitation is that you can do 4 partial writes and then you must do an
erase.

If you search for 'partial page NAND' you'll get a series of hits from
different vendors.  The link below is for a conference presentation
from Micron.  In the section about bit disturb they explain what's
happening to prevent unlimited writing.

http://www.broadbandreports.com/r0/download/1507743~59e7b9dda2c0e0a0f7ff119a7611c641/flash_mem_summit_jcooke_inconvenient_truths_nand.pdf


As another data point, the link below discusses limitations in doing
this with a Spansion NOR multiple bit/cell NOR flash:

http://www.spansion.com/Support/AppNotes/BitFieldProgMirrorBit_AN_A1_e.pdf

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] cyg_flash_program_mask

[Ross Younger]

On 16/02/11 21:07, Andrew Dyer wrote:
> This is a recent Micron 2Gb large page NAND (I don't have the
> datasheet handy, but I believe it was the M60A generation).  The
> limitation is that you can do 4 partial writes and then you must do an
> erase.

FWIW the Samsung large-page parts I've worked with recently (several of 
them - at least 1Gbit and 2Gbit, I don't have the part numbers to hand) 
have all had similar restrictions.

Ross

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: cyg_flash_program_mask

[Tarmo Kuuse]

Hi Tom,

On 15.02.2011 19:18, Tom Schouten wrote:
> I found the other behaviour in the atmel dataflash implementation
> (current CVS tree).
>
> In
> packages/devs/flash/atmel/dataflash/current/src/devs_flash_atmel_dataflash_flash_dev_funs.c:
>
> In function df_flash_program()
> cyg_dataflash_program_buf(&priv->dev, 1, page, true)
>
> In
> packages/devs/flash/atmel/dataflash/current/src/devs_flash_atmel_dataflash.c:
>
>
> int
> cyg_dataflash_program_buf(cyg_dataflash_device_t *dev,
> cyg_uint8 buf_num,
> cyg_uint32 page_num,
> cyg_bool erase)
>
> Hence for atmel dataflash the "erase" is always true.

There is probably a simple explanation for that. The Atmel Dataflash is 
not your garden-variety NOR flash. It requires erasing before 
programming. Quoting section 5.2.3 from AT45DB021B data sheet:

"Successive page programming operations without doing a page erase are 
not recommended".

--
Kind regards,
Tarmo Kuuse


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: cyg_flash_program_mask

[Grant Edwards]

On 2011-02-18, Ross Younger <ecos@impropriety.org.uk> wrote:
> On 16/02/11 21:07, Andrew Dyer wrote:
>> This is a recent Micron 2Gb large page NAND (I don't have the
>> datasheet handy, but I believe it was the M60A generation).  The
>> limitation is that you can do 4 partial writes and then you must do an
>> erase.
>
> FWIW the Samsung large-page parts I've worked with recently (several of 
> them - at least 1Gbit and 2Gbit, I don't have the part numbers to hand) 
> have all had similar restrictions.

I've been looking at a variety of NAND flash datasheets from several
vendors over the past 6 months, and it's a pretty common restriction.

-- 
Grant Edwards               grant.b.edwards        Yow! I'll show you MY
                                  at               telex number if you show me
                              gmail.com            YOURS ...


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss