<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/32957/write-erase-time-for-a-sector-in-89v51rd2</link><description> 
hi, 

 
i would like to know the write and erase times for a sector for a
89V51RD2 microcontroller. if you have this info please share it. 

 
Also i see from the datasheet that the write/erase cycles are
10000. is this for one sector or for the entire</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/thread/140728?ContentTypeID=1</link><pubDate>Mon, 19 May 2014 00:42:56 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:44f90e8f-c3c8-4246-ac8a-a1fbb175022c</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Normally, writes are fast. It&amp;#39;s normally the erase to make the
flash sector ready to accept data that takes lots of time. Which
means that having one sector pre-erased can reduce your power needs -
but if that write fails you lost your margin for a second
attempt.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/thread/131411?ContentTypeID=1</link><pubDate>Mon, 19 May 2014 00:04:24 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9509da1b-2f03-4bd4-a17c-e346442c1eca</guid><dc:creator>veeresh ambe</dc:creator><description>&lt;p&gt;&lt;p&gt;
ofcourse i will detect the powerfail as early as possible.&lt;/p&gt;

&lt;p&gt;
regarding the capacitance values i need to know the write time for
calculating the capacitance values. and the current consumed by the
microcontroller during the write. this value i can get by monitoring
the microcontroller for some time during operation but i am still
stuck on the write time.&lt;/p&gt;

&lt;p&gt;
regarding the write time i thought i could calculate it roughly by
flashing a hex file of a know size using the FlashMagic SW. i know
that this uses isp routines while my application will use iap
routines but the time for writing a byte to the flash would be the
same?&lt;/p&gt;

&lt;p&gt;
thanks for your inputs. your inputs have helped me a lot!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/thread/140739?ContentTypeID=1</link><pubDate>Sun, 18 May 2014 23:51:32 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2bc7ce34-ef23-4522-89c6-85d5b91531d7</guid><dc:creator>veeresh ambe</dc:creator><description>&lt;p&gt;&lt;p&gt;
thanks for your reply...this seems to be a good method. i will use
it.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/thread/137130?ContentTypeID=1</link><pubDate>Fri, 16 May 2014 06:13:25 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6cefc819-683a-44a5-a16e-5c410c014e5a</guid><dc:creator>&amp;#178;erik malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
you are overcomplicating it&lt;br /&gt;
use a struct&lt;/p&gt;

&lt;pre&gt;
x
x
x
cksm
used
&lt;/pre&gt;

&lt;p&gt;
to write after start/power fail:&lt;br /&gt;
start from the beginning, the first struct where used is ff is where
you write then keep a RAM pointer till next fail&lt;/p&gt;

&lt;p&gt;
to read after powerfail finf the first where used is ff go one
back, if cksm is OK, use it, if not, go one more back&lt;/p&gt;

&lt;p&gt;
i have done this many times, the abive just works&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/thread/128588?ContentTypeID=1</link><pubDate>Fri, 16 May 2014 04:13:40 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:2681eff1-9f69-44f0-b7f1-d7259d041530</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Remember that flash writes requires a constant voltage - so you
need to catch power failures by looking at some voltage on the
outside of your regulator. And have large enough capacitors that the
regulator can supply a valid voltage until you are done.&lt;/p&gt;

&lt;p&gt;
Not only that - the capacitors must hold for long enough that they
support a write failure in which case you might have to try a second
time by maybe failing your current sector and move to the next
sector. Or you might step back in time with on average 5k saves but
potentially a full 10k saves.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/thread/137134?ContentTypeID=1</link><pubDate>Fri, 16 May 2014 04:09:36 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6e606b9d-3ab3-4550-9063-5f7462ab1b38</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
It&amp;#39;s trivial to rate code.&lt;/p&gt;

&lt;p&gt;
How to select which sector to use:&lt;/p&gt;

&lt;pre&gt;
save_nonvolatile() {
    mon_debug(&amp;quot;saving nonvolatile data.&amp;quot;);
    build_sector_data(sector_data);
    for (;;) {
        sequence_count++;
        patch_sector_data_with_sequence(sector_data,++sequence_count);
        eval_crc_for_sector(sector_data);
        sector_num_to_use = sequence_count % num_sectors;
        program_sector(sector_num_to_use,sector_data);
        if (verify_sector(sector_num_to_use)) break;
        mon_debug(&amp;quot;failed saving to sector %u - stepping to next.&amp;quot;,sector_num_to_use);
    }
}
&lt;/pre&gt;

&lt;p&gt;
Potentially you could keep a list of known broken sectors to
instantly skip, but that optimization might not be needed.&lt;/p&gt;

&lt;p&gt;
And trivial to find current sector too by reading all sectors,
while ignoring all sectors with invalid crc. The highest sequence
count found represent the surviving sector with newest data. sequence
number+1 modulo sector count represents the next sector to use.
Sequence number divided by number of sectors represents the amount of
wear - divide by the rated wear count and you get how much of total
life expectancy you have consumed.&lt;/p&gt;

&lt;p&gt;
So your life is less complicated if you rotate through the
sectors. If you wear one sector at a time, then you need to add lots
of &amp;quot;interesting&amp;quot; backup functionality for trying to recover after a
sector failure. And remember that if sector n fails after 9000
writes, then sector n-1 contains 9000 writes old information which
might represent days, weeks or months old data. With a continuous
rotation around all sectors, then the previous sector is just one
write old. So you might just step back in time 10 minutes by having
to go back to the previous sector to recover.&lt;/p&gt;

&lt;p&gt;
Your variant with a sector at a time really is extremely
complicated. You would need to add own ECC (error correcting code) in
your sector data to give your code a chance to recover data even if
there are a number of bit errors in the written sector data. And that
ECC would still not help you if you lost the power just after you
erased the sector but before you had time to write down the updated
data. With a rotation scheme, a power loss at that time doesn&amp;#39;t
matter much becuase you haven&amp;#39;t erased your previous save. So you
have a safe restore point.&lt;/p&gt;

&lt;p&gt;
My solution is KISS - keep it simple stupid. Easy to implement and
with excellent recovery options.&lt;/p&gt;

&lt;p&gt;
Your solution might sound KISS but is hard to implement and even
when well-implemented still leaves situations you can&amp;#39;t recover from
without backing in time with a huge amount.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/thread/117554?ContentTypeID=1</link><pubDate>Fri, 16 May 2014 02:55:32 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7765803d-333c-47f6-bed0-453004d6e006</guid><dc:creator>veeresh ambe</dc:creator><description>&lt;p&gt;&lt;p&gt;
well i will initiate the write after i detect the powerfail so i
think there is no question of a powerfail during the writing to
flash.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/thread/128604?ContentTypeID=1</link><pubDate>Fri, 16 May 2014 02:50:27 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:67426929-2e25-43be-93c7-af82a57ea164</guid><dc:creator>veeresh ambe</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;b&gt;But running 10k/sector and then start the next sector would
mean the code has already come to the roads end when it has done 10k
on the last sector - it would take extra code to get it to return to
the first sector and try to push from 10k to 11k.&lt;/b&gt;&lt;br /&gt;
sorry but i didnt get this part. i would not come back to the first
sector after it finishes the specified number of writes. there would
be no question of pushing it from 10k to 11k?&lt;/p&gt;

&lt;p&gt;
and i did get the point of rotating through the sectors...it makes
my life a little difficult though :)...i have to code all of these
things in....although i suppose i might find some ready code for it
on the net.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/thread/120327?ContentTypeID=1</link><pubDate>Fri, 16 May 2014 02:31:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c2333efc-64a4-4140-ab9c-a5bd603cbf04</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Yes, the rotation between sectors means that there is some trace
of sequence numbers&lt;/p&gt;

&lt;p&gt;
So the sectors may contain (after a power failure in the middle of
an update)&lt;/p&gt;

&lt;pre&gt;
SEQ  CRC
1017 OK
1018 OK
1019 OK
1020 OK &amp;lt;= so this is the newest surviving flash sector
broken  &amp;lt;= some failure (power, bug, lockup, broken flash sector) during this write.
1012 OK
1013 OK
1014 OK
1015 OK
1016 OK
&lt;/pre&gt;

&lt;p&gt;
And with 10 sectors in circulation, a counter of 1020 would
indicate that each sector has seen about 100 rewrite cycles which
would be 1% of what the 10k from the specification.&lt;/p&gt;

&lt;p&gt;
Rotating through the sectors is a winner when it comes to
availability of redundant data.&lt;/p&gt;

&lt;p&gt;
This rotation also means that if the unit actually manages 20k
cycles/sector then the unit will stay alive for twice as many total
cycles. But running 10k/sector and then start the next sector would
mean the code has already come to the roads end when it has done 10k
on the last sector - it would take extra code to get it to return to
the first sector and try to push from 10k to 11k.&lt;/p&gt;

&lt;p&gt;
Next thing - the count isn&amp;#39;t absolute but the retention gets worse
as they get older. Wearing a single sector at a time means that even
a new unit will spend time depending on a sector with a very high
wear level before it switches to a brand new sector.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/thread/84904?ContentTypeID=1</link><pubDate>Fri, 16 May 2014 02:09:29 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ee56eca4-3047-4b92-b74b-9b2ef0142998</guid><dc:creator>flash user</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;write time is especially important for me as i want to store
some data if there is a power failure.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Consider what might happen if you lose power &lt;b&gt;while&lt;/b&gt; you are
in the process of writing to flash.&lt;/p&gt;

&lt;p&gt;
Best to use at least two sectors and keep a record of last good
data. So if power fails during an update, you can revert back to the
previous good copy.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/thread/81888?ContentTypeID=1</link><pubDate>Fri, 16 May 2014 01:54:11 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:133226a9-9568-4e00-aa7d-1dd1517a7688</guid><dc:creator>veeresh ambe</dc:creator><description>&lt;p&gt;&lt;p&gt;
thanks for your reply...rotating through the sectors seems to be a
good option. does it really make any difference if i rotate through
sectors or if i wear out a sector at a time in terms of the life of
the block?&lt;/p&gt;

&lt;p&gt;
i had considered that i would have to store redundant info to know
which sector is broken and which is current and how many
writes/erases have been performed on the sector and so on...to avoid
this additional overhead i had thought of using only one sector and
then moving onto the next after a certain no of writes/erases.&lt;/p&gt;

&lt;p&gt;
btw do you know what are the write and erase times? i could not
find this info anywhere. it is also not available in the datasheet.
write time is especially important for me as i want to store some
data if there is a power failure.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: write/erase time for a sector in 89V51RD2</title><link>https://community.arm.com/thread/68682?ContentTypeID=1</link><pubDate>Thu, 15 May 2014 02:40:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:4aa906fa-be64-43fa-9256-09cf29f3e8bc</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
The number of erase cycles is per block.&lt;/p&gt;

&lt;p&gt;
But you do not normally design code to wear out a single flash
sector first. You instead rotate through the available sectors to get
an even wear.&lt;/p&gt;

&lt;p&gt;
First off - there isn&amp;#39;t a hard limit to number of erase cycles.
The sectors normally can handle way more cycles but it depends a lot
on ambient temperature, exact supply voltages etc. One interesting
thing to consider - if you do have a broken flash sector, how will
you know it is broken? How will you know which flash sector us the
current to read out data from? And which is the next one to write to?
You need some redundant storage of your write counters or your
&amp;quot;current&amp;quot; pointers.&lt;/p&gt;

&lt;p&gt;
If you rotate through all available sectors, then you can store a
constantly increasing sequence number + some crc or other checksum in
every sector. That means that with one sector broken, you can still
figure out which sector is the most recent with data and which sector
would be the next one to use.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>