NV counter in flash

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

NV counter in flash

Veronica Merryfield-3
Anyone else tried this? Good/bad?

I have a project with a PIC24 that is using the self programming of flash to store some non-volatile data including a slow count - up time in minute increments. The counter is part of a larger structure of NV data.

I want to avoid rewriting the whole block each time the counter is updated and came up with the following.

Flash when erased reads all ones. Writing changes ones to zeros. Overwriting can happen but only to change ones to zeros (I assume the PIC flash behaves like other NOR flash in this regard). By setting aside a byte or two as a counter, each count could be represented as a zeroed bit, each bit zeroed being an increment. When all are zeroed, a real counter is updated with the number of bits at zero and the process can start over. As a further enhancement, each time the block is written for an update of something else, the counter would be updated from the bit count and the bit counter erased to go again.



--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: NV counter in flash

Brent Brown
On 20 Sep 2012 at 20:39, Veronica Merryfield wrote:

> Anyone else tried this? Good/bad?
>
> I have a project with a PIC24 that is using the self programming of
> flash to store some non-volatile data including a slow count - up
> time in minute increments. The counter is part of a larger structure
> of NV data.
>
> I want to avoid rewriting the whole block each time the counter is
> updated and came up with the following.
>
> Flash when erased reads all ones. Writing changes ones to zeros.
> Overwriting can happen but only to change ones to zeros (I assume
> the PIC flash behaves like other NOR flash in this regard). By
> setting aside a byte or two as a counter, each count could be
> represented as a zeroed bit, each bit zeroed being an increment.
> When all are zeroed, a real counter is updated with the number of
> bits at zero and the process can start over. As a further
> enhancement, each time the block is written for an update of
> something else, the counter would be updated from the bit count and
> the bit counter erased to go again.

Your idea sounds feasible. Each consecutive bit cleared will represent 1 minute
though so you only store 8 x 1 minute ticks in a byte, vs 256 if stored simply as an 8
bit count.

As the bits are cleared in sequence you can check for an error if a bit is cleared out
of sequence, but what to do with it then... reset to zero, flag an error? Depends on
your application.

I have implemented an hours counter for an industrial machine before. It was
surprisingly quite a lot of work to come up with something that worked reliably and
covered all the "requirements" of PIC EEPROM usage, ie. endurance, refreshing,
etc.

I used a 4 byte counter incrementing every 0.001 hours (3.6 seconds) of engine
running time, but only update the values in EEPROM every 0.1 hours or whenever
power failure is iminent. Also, the EEPROM values are stored in triplicate, using
best 2 out of 3 method to ignore and repair errors, plus the data is rotated around
the EEPROM to perform wear levelling and make sure it gets refreshed regularly.

Hope this helps~!
--
Brent Brown, Electronic Design Solutions
9 Titoki Place, Pukete,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: +64 27 433 4069
eMail:  [hidden email]



--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

RE: NV counter in flash

Michael Rigby-Jones-2
In reply to this post by Veronica Merryfield-3


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Veronica Merryfield
Sent: 21 September 2012 04:39
To: Microcontroller discussion list - Public.
Subject: [PIC] NV counter in flash

>Anyone else tried this? Good/bad?
>
>I have a project with a PIC24 that is using the self programming of flash to store some
> non-volatile data including a slow count - up time in minute increments. The counter
>is part of a larger structure of NV data.
>
>I want to avoid rewriting the whole block each time the counter is updated and came
> up with the following.

>Flash when erased reads all ones. Writing changes ones to zeros. Overwriting can
>happen but only to change ones to zeros (I assume the PIC flash behaves like other
>NOR flash in this regard). By setting aside a byte or two as a counter, each count could
> be represented as a zeroed bit, each bit zeroed being an increment. When all are
>zeroed, a real counter is updated with the number of bits at zero and the process can
> start over. As a further enhancement, each time the block is written for an update of
>something else, the counter would be updated from the bit count and the bit counter
>erased to go again.


The way I implemented a similar scheme was to put all the data I wanted to update regularly in a structure, and included a counter and a checksum within the structure.  I then defined an area of EEPROM to use which was a multiple of the structure size.  To save the new values to EEPROM, I increment the counter, update the checksum and write to the next slot in EEPROM.  When I reach the end of the EEPROM area I wrap back to the start.  In your case the counter can be the run time value.

At power on, you scan the EEPROM area to find the latest record (i.e. highest count) with a valid checksum.  The location of the EEPROM slot with the latest record must be stored in a variable, as this determines where your next write will start.   If the time count could ever roll over then the record with the highest value is no longer the latest one.  However you can detect this by storing the minimum and maximum values when you scan the EEPROM.  If the difference between minimum and maximum is larger than the number of records in the EEPROM, then a rollover has occurred and you can then determine the newest value that has been written after the roll over.

This scheme spreads the EEPROM wear over a selectable range of cells, and also protects against corruption.  If a record gets corrupted the last good one is automatically used.

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: NV counter in flash

Sean Breheny
I think Veronica is trying to do this with FLASH, though, not EEPROM,
so she is trying to avoid performing an erase of the entire block very
frequently. I suppose that Mike's method might allow her to only erase
the block when it was full of individual "time structures".

Sean


On Fri, Sep 21, 2012 at 6:18 AM, Michael Rigby-Jones
<[hidden email]> wrote:

>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Veronica Merryfield
> Sent: 21 September 2012 04:39
> To: Microcontroller discussion list - Public.
> Subject: [PIC] NV counter in flash
>
>>Anyone else tried this? Good/bad?
>>
>>I have a project with a PIC24 that is using the self programming of flash to store some
>> non-volatile data including a slow count - up time in minute increments. The counter
>>is part of a larger structure of NV data.
>>
>>I want to avoid rewriting the whole block each time the counter is updated and came
>> up with the following.
>
>>Flash when erased reads all ones. Writing changes ones to zeros. Overwriting can
>>happen but only to change ones to zeros (I assume the PIC flash behaves like other
>>NOR flash in this regard). By setting aside a byte or two as a counter, each count could
>> be represented as a zeroed bit, each bit zeroed being an increment. When all are
>>zeroed, a real counter is updated with the number of bits at zero and the process can
>> start over. As a further enhancement, each time the block is written for an update of
>>something else, the counter would be updated from the bit count and the bit counter
>>erased to go again.
>
>
> The way I implemented a similar scheme was to put all the data I wanted to update regularly in a structure, and included a counter and a checksum within the structure.  I then defined an area of EEPROM to use which was a multiple of the structure size.  To save the new values to EEPROM, I increment the counter, update the checksum and write to the next slot in EEPROM.  When I reach the end of the EEPROM area I wrap back to the start.  In your case the counter can be the run time value.
>
> At power on, you scan the EEPROM area to find the latest record (i.e. highest count) with a valid checksum.  The location of the EEPROM slot with the latest record must be stored in a variable, as this determines where your next write will start.   If the time count could ever roll over then the record with the highest value is no longer the latest one.  However you can detect this by storing the minimum and maximum values when you scan the EEPROM.  If the difference between minimum and maximum is larger than the number of records in the EEPROM, then a rollover has occurred and you can then determine the newest value that has been written after the roll over.
>
> This scheme spreads the EEPROM wear over a selectable range of cells, and also protects against corruption.  If a record gets corrupted the last good one is automatically used.
>
> Mike
>
> =======================================================================
> This e-mail is intended for the person it is addressed to only. The
> information contained in it may be confidential and/or protected by
> law. If you are not the intended recipient of this message, you must
> not make any use of this information, or copy or show it to any
> person. Please contact us immediately to tell us that you have
> received this e-mail, and return the original to us. Any use,
> forwarding, printing or copying of this message is strictly prohibited.
> No part of this message can be considered a request for goods or
> services.
> =======================================================================
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: NV counter in flash

Isaac Marino Bavaresco
In reply to this post by Veronica Merryfield-3
Em 21/09/2012 00:39, Veronica Merryfield escreveu:
> Anyone else tried this? Good/bad?
>
> I have a project with a PIC24 that is using the self programming of flash to store some non-volatile data including a slow count - up time in minute increments. The counter is part of a larger structure of NV data.
>
> I want to avoid rewriting the whole block each time the counter is updated and came up with the following.
>
> Flash when erased reads all ones. Writing changes ones to zeros. Overwriting can happen but only to change ones to zeros (I assume the PIC flash behaves like other NOR flash in this regard). By setting aside a byte or two as a counter, each count could be represented as a zeroed bit, each bit zeroed being an increment. When all are zeroed, a real counter is updated with the number of bits at zero and the process can start over. As a further enhancement, each time the block is written for an update of something else, the counter would be updated from the bit count and the bit counter erased to go again.


It may work, but first check what the datasheet of the PIC24FJ64GA004
family (39881D) says:

"With RTSP, the user may write program memory data in blocks of 64
instructions (192 bytes) at a time, and erase program memory in blocks
of 512 instructions (1536 bytes) at a time."


Once I read an NXP document (about an LPC ARM micro-controller)
explaining why you must not write twice the same FLASH block without
erasing:

Each FLASH block has a hidden ECC used by the FLASH controller to detect
and correct errors, improving the processor's reliability.
When you write a block, the ECC is written at the same time. If you
program the same block again changing some bits from one to zero, the
ECC is written again also, but certainly the new value anded with the
old value will result in an invalid ECC code and the FLASH controller
will report the block as bad and will not be able to correct the "error".


I'm sure the same doesn't apply to PICs, but it is good to have that in
mind.


Perhaps the granularities of the PIC24 you are using is different.
For processors able to write one word at a time (rarer and rarer
nowadays), Microchip has an application not about emulating EEPROM in
FLASH, AN1095:
<http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en530593>


Best regards,

Isaac

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: NV counter in flash

Isaac Marino Bavaresco
Em 21/09/2012 10:00, Isaac Marino Bavaresco escreveu:

> Em 21/09/2012 00:39, Veronica Merryfield escreveu:
>> Anyone else tried this? Good/bad?
>>
>> I have a project with a PIC24 that is using the self programming of flash to store some non-volatile data including a slow count - up time in minute increments. The counter is part of a larger structure of NV data.
>>
>> I want to avoid rewriting the whole block each time the counter is updated and came up with the following.
>>
>> Flash when erased reads all ones. Writing changes ones to zeros. Overwriting can happen but only to change ones to zeros (I assume the PIC flash behaves like other NOR flash in this regard). By setting aside a byte or two as a counter, each count could be represented as a zeroed bit, each bit zeroed being an increment. When all are zeroed, a real counter is updated with the number of bits at zero and the process can start over. As a further enhancement, each time the block is written for an update of something else, the counter would be updated from the bit count and the bit counter erased to go again.
>
> It may work, but first check what the datasheet of the PIC24FJ64GA004
> family (39881D) says:
>
> "With RTSP, the user may write program memory data in blocks of 64
> instructions (192 bytes) at a time, and erase program memory in blocks
> of 512 instructions (1536 bytes) at a time."
>
>
> Once I read an NXP document (about an LPC ARM micro-controller)
> explaining why you must not write twice the same FLASH block without
> erasing:
>
> Each FLASH block has a hidden ECC used by the FLASH controller to detect
> and correct errors, improving the processor's reliability.
> When you write a block, the ECC is written at the same time. If you
> program the same block again changing some bits from one to zero, the
> ECC is written again also, but certainly the new value anded with the
> old value will result in an invalid ECC code and the FLASH controller
> will report the block as bad and will not be able to correct the "error".
>
>
> I'm sure the same doesn't apply to PICs, but it is good to have that in
> mind.
>
>
> Perhaps the granularities of the PIC24 you are using is different.
> For processors able to write one word at a time (rarer and rarer
> nowadays), Microchip has an application not about emulating EEPROM in
> FLASH, AN1095:
> <http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en530593>
>
>
> Best regards,
>
> Isaac

Veronica,


Which PIC24 are you using?

After replying I noticed that one program block for the PIC24FJ64GA004
has 1536, and one day has 1440 minutes.
If you succeed in changing one bit at a time, you will need to erase the
block only once a day.

The data-sheet states that the FLASH endurance is 10000 program-erase
cycles.
If each programming cycle wears the FLASH as much as the erase cycle,
then your PIC will last just some weeks.

I'm inclined to believe that re-programming a bit with the same value it
has already causes minimal wear to the memory cells, because no
electrons are flowing through the dielectric.

It may work.


Best regards,

Isaac

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: NV counter in flash

Veronica Merryfield-3
In reply to this post by Isaac Marino Bavaresco
On 2012-09-21, at 5:30 AM, Sean Breheny <[hidden email]> wrote:

> I think Veronica is trying to do this with FLASH, though, not EEPROM,

Correct, using the on board flash.

On 2012-09-21, at 6:00 AM, Isaac Marino Bavaresco <[hidden email]> wrote:

> It may work, but first check what the datasheet of the PIC24FJ64GA004
> family (39881D) says:

I'm using a PIC24FG256GB110

> "With RTSP, the user may write program memory data in blocks of 64
> instructions (192 bytes) at a time, and erase program memory in blocks
> of 512 instructions (1536 bytes) at a time."

39697B Section 4.2 "The PIC24F Flash program memory array is organized
into rows of 64 instructions or 192 bytes. RTSP allows
the user to erase blocks of eight rows (512 instructions)
at a time and to program one row at a time. It is also
possible to program single words."

There is a programming example in section 4.6.2 for a single word.

However, there is a note "Writing to a location multiple times without
erasing is not recommended."

In practise I would probably have a 4 byte 'tally' counter with a bit change per 2 minutes giving me an hour although I could use more bytes for a long time between erases.

I have submitted a ticket to MC to ask them and ask about the basis of the note. We'll see what they say.

As ever, thanks everyone

Veronica


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: NV counter in flash

Isaac Marino Bavaresco
Em 21/09/2012 16:21, Veronica Merryfield escreveu:

> On 2012-09-21, at 5:30 AM, Sean Breheny <[hidden email]> wrote:
>
>> I think Veronica is trying to do this with FLASH, though, not EEPROM,
> Correct, using the on board flash.
>
> On 2012-09-21, at 6:00 AM, Isaac Marino Bavaresco <[hidden email]> wrote:
>
>> It may work, but first check what the datasheet of the PIC24FJ64GA004
>> family (39881D) says:
> I'm using a PIC24FG256GB110
>
>> "With RTSP, the user may write program memory data in blocks of 64
>> instructions (192 bytes) at a time, and erase program memory in blocks
>> of 512 instructions (1536 bytes) at a time."
> 39697B Section 4.2 "The PIC24F Flash program memory array is organized
> into rows of 64 instructions or 192 bytes. RTSP allows
> the user to erase blocks of eight rows (512 instructions)
> at a time and to program one row at a time. It is also
> possible to program single words."
>
> There is a programming example in section 4.6.2 for a single word.
>
> However, there is a note "Writing to a location multiple times without
> erasing is not recommended."
>
> In practise I would probably have a 4 byte 'tally' counter with a bit change per 2 minutes giving me an hour although I could use more bytes for a long time between erases.
>
> I have submitted a ticket to MC to ask them and ask about the basis of the note. We'll see what they say.
>
> As ever, thanks everyone
>
> Veronica


Veronica,


I don't know if it is feasible for you, but I already used a different
approach:

Keep the count in RAM and use the low voltage detection interrupt to
write the count to the FLASH.
You will need just one erase per power-up. Use two blocks in a
"flip-flop" fashion. Keep a counter of power-ups and save it together
with the time counter.
At power-up check to see what is the newest block and read the data from
it and if the other block is not erased, erase it.

When the low voltage detect happens, all you need to do is to write the
counters to the erased block.

It is good if you put a large electrolytic capacitor before your voltage
regulator.


Best regards,

Isaac

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist