[ECOS] cyg_flash_program_mask

Tom Schouten tom@zwizwa.be
Tue Feb 15 18:40:00 GMT 2011


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



More information about the Ecos-discuss mailing list