You need to answer your own question. Calculate the size of the data
you plan to store. Compare that to the available memory space on
whatever you choose to use.
________________________________
From: m... [mailto:m...] On Behalf
Of Technical Kripa
Sent: Wednesday, November 19, 2008 11:16 AM
To: m...
Subject: Re: [msp430] Re: MSP430 flash memory
The answer to my original question(whether or not use the flash for
datalogging of events) has still not been settled inspite of all these
discussions..
well...I would take Dave's word (though I dont know why!) that MSP430
flash is seamless and would use it for datalogging. I wouldnt want to
but I wont care much if the flash dies after one year of good service
(one year is the waranty period for the application by the way:-). Even
otherwise, If I miss say 0.1% of datalogging events, it shouldnt matter
much.
Apart from the ruggedness of the flash issue, is the memory size of 149
sufficient for my application (details of logging events are in my
earlier post)?
I'm assuming you have set the proper timing parameters of the FLASH,
yes? The new 5000 series parts handle that 4 u, but the older ones
have you set it. I set the timing right smack in the middle of the
specification on F149 and F169 parts and they have been running in
very remote locations for many years without seeing a human hand. The
FLASH is loaded over a radio link and can be anything from simple
device configuration (a single FLASH block) to re-programming of the
entire device (first to serial EEPROM, then to FLASH once the EEPROM
image is verified). This process has worked thousands of times in
outdoor, harsh environments and over temperature extremes. I have
never seen a single problem that was found to be a FLASH error, and I
would know if there were because I would get an automatically
generated "CRC Fail" email from every device that did not program the
FLASH properly, or I would get a visit from a frowning manager if the
device stopped working after the FLASH upload.
Are you sure your hardware is okay? Ample power decoupling caps? Good
power during the erase/write cycles?
- Dave -
--- In msp430@yahoogroups. com, "Dan Muzzey" wrote: >
> >>>snip>>>
> What kind of problems have you had with FLASH? If you cannot trust it
> for data then you most certainly cannot trust it for program storage.
>
> >>>snip>>> I've never had a problem loosing programs. Then again, I use
an
> external programmer to program the code. The MSP does not change the
> program with the FRAM. I would not trust the MSP to update its own
> program through some serial port.
>
> The only thing I can think of, and I am definitely not a chip designer
> (this is all a guess), is that the MSP is very susceptible to noise
> fluctuations on the power line when programming its own flash. Some
> lots are more susceptible than others. Every once in a while, a lot
> gets out that is really bad. The noise creates a marginal write to
> flash. Maybe this has something to do with the low power features of
> the chip. When TI designed the new chips they implemented a new feature > to check for this marginal write to flash. But they
screwed it up and
> it didn't work correctly. I've heard they have now fixed it but
the
> question remains. Why does the chip have to have a feature where it
> will check and make sure that it actually did what it was told to do? I > would think that checking the contents of FLASH after
a write would be
> more than adequate. Guess that might not be so. Imagine if the RAM
> worked the same way.
>
>
You did get answers, but they were varied. i've been using the internal
flash memory to log data for yars, including using continuously rolling
storage,a dn provided you have a sound write algortihm and make sure
that you aren't trying to write data under extreme conditinns of voltage
or temperature (I limit mine to 3V). as to wheteh the memory is large
enough nobody but you can work that out. you know the size of each
stored entry, and you should know how much memory is left after your
code is written. you can also adopt a wide range of strategies to
minimise the amount of storage required.
For example i have data loggers that run on the 2012 and 2013 micros,
and have almost a full 2k sample capability at 12 bit sample size, so
again the only one who can say if the 149 memory is big enough is you.
Al
Technical Kripa wrote:
>The answer to my original question(whether or not use
the flash for datalogging of events) has still not been settled inspite of all
these discussions..
>
>well...I would take Dave's word (though I dont know why!) that MSP430
flash is seamless and would use it for datalogging. I wouldnt want to but I wont
care much if the flash dies after one year of good service (one year is the
waranty period for the application by the way:-). Even otherwise, If I miss say
0.1% of datalogging events, it shouldnt matter much.
>
>Apart from the ruggedness of the flash issue, is the memory size of 149
sufficient for my application (details of logging events are in my earlier
post)?
>
>Thanks n regards,
>Sanmeet
>
>________________________________
>From: desertrc_tucson
>To: m...
>Sent: Monday, 17 November, 2008 8:34:58 PM
>Subject: [msp430] Re: MSP430 flash memory
>I'm assuming you have set the proper timing parameters of the FLASH,
>yes? The new 5000 series parts handle that 4 u, but the older ones
>have you set it. I set the timing right smack in the middle of the
>specification on F149 and F169 parts and they have been running in
>very remote locations for many years without seeing a human hand. The
>FLASH is loaded over a radio link and can be anything from simple
>device configuration (a single FLASH block) to re-programming of the
>entire device (first to serial EEPROM, then to FLASH once the EEPROM
>image is verified). This process has worked thousands of times in
>outdoor, harsh environments and over temperature extremes. I have
>never seen a single problem that was found to be a FLASH error, and I
>would know if there were because I would get an automatically
>generated "CRC Fail" email from every device that did not program the
>FLASH properly, or I would get a visit from a frowning manager if the
>device stopped working after the FLASH upload.
>
>Are you sure your hardware is okay? Ample power decoupling caps? Good
>power during the erase/write cycles?
>
>- Dave -
>
>--- In msp430@yahoogroups. com, "Dan Muzzey" wrote:
>
>
>>
>>
>>
>>>>>snip>>>
>>>>>
>>>>>
>>What kind of problems have you had with FLASH? If you cannot trust it
>>for data then you most certainly cannot trust it for program storage.
>>
>>
>>
>>>>>snip>>>
>>>>>
>>>>>
>>I've never had a problem loosing programs. Then again, I use an
>>external programmer to program the code. The MSP does not change the
>>program with the FRAM. I would not trust the MSP to update its own
>>program through some serial port.
>>
>>The only thing I can think of, and I am definitely not a chip designer
>>(this is all a guess), is that the MSP is very susceptible to noise
>>fluctuations on the power line when programming its own flash. Some
>>lots are more susceptible than others. Every once in a while, a lot
>>gets out that is really bad. The noise creates a marginal write to
>>flash. Maybe this has something to do with the low power features of
>>the chip. When TI designed the new chips they implemented a new feature
>>to check for this marginal write to flash. But they screwed it up and
>>it didn't work correctly. I've heard they have now fixed it but
the
>>question remains. Why does the chip have to have a feature where it
>>will check and make sure that it actually did what it was told to do? I
>>would think that checking the contents of FLASH after a write would be
>>more than adequate. Guess that might not be so. Imagine if the RAM
>>worked the same way.
>>
>>
>>
>>
> Add more friends to your messenger and enjoy! Go to
http://messenger.yahoo.com/invite/
>
>
>
Reply by old_cow_yellow●November 19, 20082008-11-19
If you are satisfied with F149, you should take a look at F249. It is
a cheaper and much improved F149. The Flash has better characteristics
and has "marginal read mode" option. (There is no "marginal write
mode", but one may intentionally or unintentionally do a marginal
write/erase.)
--- In m..., Technical Kripa wrote: >
> The answer to my original question(whether or not use the flash for datalogging of events) has still not been settled inspite of all these
discussions.. >
> well...I would take Dave's word (though I dont know why!) that MSP430 flash is seamless and would use it for datalogging. I wouldnt
want to but I wont care much if the flash dies after one year of good
service (one year is the waranty period for the applicationby the
way:-). Even otherwise, If I miss say 0.1% of datalogging events, it
shouldnt matter much. >
> Apart from the ruggedness of the flash issue, is the memory size of 149 sufficient for my application (details of logging events are in my
earlier post)? >
> Thanks n regards,
> Sanmeet
>
>
>
> ________________________________
> From: desertrc_tucson
> To: m...
> Sent: Monday, 17 November, 2008 8:34:58 PM
> Subject: [msp430] Re: MSP430 flash memory
>
>
> I'm assuming you have set the proper timing parameters of the FLASH,
> yes? The new 5000 series parts handle that 4 u, but the older ones
> have you set it. I set the timing right smack in the middle of the
> specification on F149 and F169 parts and they have been running in
> very remote locations for many years without seeing a human hand. The
> FLASH is loaded over a radio link and can be anything from simple
> device configuration (a single FLASH block) to re-programming of the
> entire device (first to serial EEPROM, then to FLASH once the EEPROM
> image is verified). This process has worked thousands of times in
> outdoor, harsh environments and over temperature extremes. I have
> never seen a single problem that was found to be a FLASH error, and I
> would know if there were because I would get an automatically
> generated "CRC Fail" email from every device that did not program the
> FLASH properly, or I would get a visit from a frowning manager if the
> device stopped working after the FLASH upload.
>
> Are you sure your hardware is okay? Ample power decoupling caps? Good
> power during the erase/write cycles?
>
> - Dave -
>
> --- In msp430@yahoogroups. com, "Dan Muzzey" wrote:
> >
> >
> >
> > >>>snip>>>
> > What kind of problems have you had with FLASH? If you cannot trust it
> > for data then you most certainly cannot trust it for program storage.
> >
> > >>>snip>>>
> >
> > I've never had a problem loosing programs. Then again, I use an
> > external programmer to program the code. The MSP does not change the
> > program with the FRAM. I would not trust the MSP to update its own
> > program through some serial port.
> >
> > The only thing I can think of, and I am definitely not a chip designer
> > (this is all a guess), is that the MSP is very susceptible to noise
> > fluctuations on the power line when programming its own flash. Some
> > lots are more susceptible than others. Every once in a while, a lot
> > gets out that is really bad. The noise creates a marginal write to
> > flash. Maybe this has something to do with the low power features of
> > the chip. When TI designed the new chips they implemented a new feature > > to check for this marginal write to flash. But they
screwed it up and
> > it didn't work correctly. I've heard they have now fixed it but
the
> > question remains. Why does the chip have to have a feature where it
> > will check and make sure that it actually did what it was told to do? I > > would think that checking the contents of FLASH
after a write would be
> > more than adequate. Guess that might not be so. Imagine if the RAM
> > worked the same way.
> >
> >
> >
> >
>
>
>
>
> Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ >
>
>
Reply by Technical Kripa●November 19, 20082008-11-19
The answer to my original question(whether or not use the flash for datalogging
of events) has still not been settled inspite of all these discussions..
well...I would take Dave's word (though I dont know why!) that MSP430 flash
is seamless and would use it for datalogging. I wouldnt want to but I wont care
much if the flash dies after one year of good service (one year is the waranty
period for the application by the way:-). Even otherwise, If I miss say
0.1% of datalogging events, it shouldnt matter much.
Apart from the ruggedness of the flash issue, is the memory size of 149
sufficient for my application (details of logging events are in my earlier
post)?
Thanks n regards,
Sanmeet
________________________________
From: desertrc_tucson
To: m...
Sent: Monday, 17 November, 2008 8:34:58 PM
Subject: [msp430] Re: MSP430 flash memory
I'm assuming you have set the proper timing parameters of the FLASH,
yes? The new 5000 series parts handle that 4 u, but the older ones
have you set it. I set the timing right smack in the middle of the
specification on F149 and F169 parts and they have been running in
very remote locations for many years without seeing a human hand. The
FLASH is loaded over a radio link and can be anything from simple
device configuration (a single FLASH block) to re-programming of the
entire device (first to serial EEPROM, then to FLASH once the EEPROM
image is verified). This process has worked thousands of times in
outdoor, harsh environments and over temperature extremes. I have
never seen a single problem that was found to be a FLASH error, and I
would know if there were because I would get an automatically
generated "CRC Fail" email from every device that did not program the
FLASH properly, or I would get a visit from a frowning manager if the
device stopped working after the FLASH upload.
Are you sure your hardware is okay? Ample power decoupling caps? Good
power during the erase/write cycles?
- Dave -
--- In msp430@yahoogroups. com, "Dan Muzzey" wrote: >
>
>
> >>>snip>>>
> What kind of problems have you had with FLASH? If you cannot trust it
> for data then you most certainly cannot trust it for program storage.
>
> >>>snip>>>
>
> I've never had a problem loosing programs. Then again, I use an
> external programmer to program the code. The MSP does not change the
> program with the FRAM. I would not trust the MSP to update its own
> program through some serial port.
>
> The only thing I can think of, and I am definitely not a chip designer
> (this is all a guess), is that the MSP is very susceptible to noise
> fluctuations on the power line when programming its own flash. Some
> lots are more susceptible than others. Every once in a while, a lot
> gets out that is really bad. The noise creates a marginal write to
> flash. Maybe this has something to do with the low power features of
> the chip. When TI designed the new chips they implemented a new feature
> to check for this marginal write to flash. But they screwed it up and
> it didn't work correctly. I've heard they have now fixed it but
the
> question remains. Why does the chip have to have a feature where it
> will check and make sure that it actually did what it was told to do? I
> would think that checking the contents of FLASH after a write would be
> more than adequate. Guess that might not be so. Imagine if the RAM
> worked the same way.
>
>
>
>
Reply by desertrc_tucson●November 17, 20082008-11-17
Hi Dan,
Thanks for the info, I will set up a similar test and see what gives
with this. You're right, I would not see the problem unless the device
reset either from POR or a panic reset as a result of a detected
problem because it only does the CRC check at run time or after a
FLASH update. I don't get very many "Device Reset" emails, so I may
not know if the FLASH is degrading. I will put in a very low bandwidth
background CRC test in future code releases to check for this.
I wonder if there is any difference between occasional writes vs.
flooding the device with back-to-back write/read cycles?
Thanks -
Dave
--- In m..., "Dan Muzzey" wrote: >
> Timing parameters set....and double checked by four independent people.
>
> Decoupling caps started out per TI recommendations then later beefed up.
> Should be excellent. Oh, did I mention that this has happened on
> several product lines? And to be fair, it was the 449 not the 149.
>
> Actually, you wouldn't get a CRC fail. What would happen is that the
> system would be updated. Everything would appear fine. Days, or weeks
> later, the system would suddenly stop working correctly. Then you would
> get angry manager syndrome. Of course, it would be really difficult to
> trace back the failure to something that happened weeks or months
> earlier.
>
> I did try some experiments with rapid writes to flash. Basically write,
> read, verify, write, read verify........On one batch of old controllers
> I went well over 200K before any fails. On the batch of new controllers
> I started seeing errors in the 100K range. My sample size was too small
> to draw any firm conclusions though. I did implement a check on the
> data write routines and basically doubled the flash life.
>
> The conclusion was to not use it for data storage on new designs and
> design in redundant data storage on existing designs.
>
> ________________________________
>
> From: m... [mailto:m...] On Behalf
> Of desertrc_tucson
> Sent: Monday, November 17, 2008 9:05 AM
> To: m...
> Subject: [msp430] Re: MSP430 flash memory
>
> I'm assuming you have set the proper timing parameters of the FLASH,
> yes? The new 5000 series parts handle that 4 u, but the older ones
> have you set it. I set the timing right smack in the middle of the
> specification on F149 and F169 parts and they have been running in
> very remote locations for many years without seeing a human hand. The
> FLASH is loaded over a radio link and can be anything from simple
> device configuration (a single FLASH block) to re-programming of the
> entire device (first to serial EEPROM, then to FLASH once the EEPROM
> image is verified). This process has worked thousands of times in
> outdoor, harsh environments and over temperature extremes. I have
> never seen a single problem that was found to be a FLASH error, and I
> would know if there were because I would get an automatically
> generated "CRC Fail" email from every device that did not program the
> FLASH properly, or I would get a visit from a frowning manager if the
> device stopped working after the FLASH upload.
>
> Are you sure your hardware is okay? Ample power decoupling caps? Good
> power during the erase/write cycles?
>
> - Dave -
>
> --- In m... , "Dan
> Muzzey" wrote:
> >
> >
> >
> > >>>snip>>>
> > What kind of problems have you had with FLASH? If you cannot trust it
> > for data then you most certainly cannot trust it for program storage.
> >
> > >>>snip>>>
> >
> > I've never had a problem loosing programs. Then again, I use an
> > external programmer to program the code. The MSP does not change the
> > program with the FRAM. I would not trust the MSP to update its own
> > program through some serial port.
> >
> > The only thing I can think of, and I am definitely not a chip designer
> > (this is all a guess), is that the MSP is very susceptible to noise
> > fluctuations on the power line when programming its own flash. Some
> > lots are more susceptible than others. Every once in a while, a lot
> > gets out that is really bad. The noise creates a marginal write to
> > flash. Maybe this has something to do with the low power features of
> > the chip. When TI designed the new chips they implemented a new
> feature
> > to check for this marginal write to flash. But they screwed it up and
> > it didn't work correctly. I've heard they have now fixed it but
the
> > question remains. Why does the chip have to have a feature where it
> > will check and make sure that it actually did what it was told to do?
> I
> > would think that checking the contents of FLASH after a write would be
> > more than adequate. Guess that might not be so. Imagine if the RAM
> > worked the same way.
> >
> >
> >
> >
>
>
>
Reply by Dan Muzzey●November 17, 20082008-11-17
Timing parameters set....and double checked by four independent people.
Decoupling caps started out per TI recommendations then later beefed up.
Should be excellent. Oh, did I mention that this has happened on
several product lines? And to be fair, it was the 449 not the 149.
Actually, you wouldn't get a CRC fail. What would happen is that the
system would be updated. Everything would appear fine. Days, or weeks
later, the system would suddenly stop working correctly. Then you would
get angry manager syndrome. Of course, it would be really difficult to
trace back the failure to something that happened weeks or months
earlier.
I did try some experiments with rapid writes to flash. Basically write,
read, verify, write, read verify........On one batch of old controllers
I went well over 200K before any fails. On the batch of new controllers
I started seeing errors in the 100K range. My sample size was too small
to draw any firm conclusions though. I did implement a check on the
data write routines and basically doubled the flash life.
The conclusion was to not use it for data storage on new designs and
design in redundant data storage on existing designs.
________________________________
From: m... [mailto:m...] On Behalf
Of desertrc_tucson
Sent: Monday, November 17, 2008 9:05 AM
To: m...
Subject: [msp430] Re: MSP430 flash memory
I'm assuming you have set the proper timing parameters of the FLASH,
yes? The new 5000 series parts handle that 4 u, but the older ones
have you set it. I set the timing right smack in the middle of the
specification on F149 and F169 parts and they have been running in
very remote locations for many years without seeing a human hand. The
FLASH is loaded over a radio link and can be anything from simple
device configuration (a single FLASH block) to re-programming of the
entire device (first to serial EEPROM, then to FLASH once the EEPROM
image is verified). This process has worked thousands of times in
outdoor, harsh environments and over temperature extremes. I have
never seen a single problem that was found to be a FLASH error, and I
would know if there were because I would get an automatically
generated "CRC Fail" email from every device that did not program the
FLASH properly, or I would get a visit from a frowning manager if the
device stopped working after the FLASH upload.
Are you sure your hardware is okay? Ample power decoupling caps? Good
power during the erase/write cycles?
- Dave -
--- In m... , "Dan
Muzzey" wrote: >
> >>>snip>>>
> What kind of problems have you had with FLASH? If you cannot trust it
> for data then you most certainly cannot trust it for program storage.
>
> >>>snip>>> I've never had a problem loosing programs. Then again, I use
an
> external programmer to program the code. The MSP does not change the
> program with the FRAM. I would not trust the MSP to update its own
> program through some serial port.
>
> The only thing I can think of, and I am definitely not a chip designer
> (this is all a guess), is that the MSP is very susceptible to noise
> fluctuations on the power line when programming its own flash. Some
> lots are more susceptible than others. Every once in a while, a lot
> gets out that is really bad. The noise creates a marginal write to
> flash. Maybe this has something to do with the low power features of
> the chip. When TI designed the new chips they implemented a new feature > to check for this marginal write to flash. But they
screwed it up and
> it didn't work correctly. I've heard they have now fixed it but
the
> question remains. Why does the chip have to have a feature where it
> will check and make sure that it actually did what it was told to do? I > would think that checking the contents of FLASH after
a write would be
> more than adequate. Guess that might not be so. Imagine if the RAM
> worked the same way.
>
>
Reply by desertrc_tucson●November 17, 20082008-11-17
I'm assuming you have set the proper timing parameters of the FLASH,
yes? The new 5000 series parts handle that 4 u, but the older ones
have you set it. I set the timing right smack in the middle of the
specification on F149 and F169 parts and they have been running in
very remote locations for many years without seeing a human hand. The
FLASH is loaded over a radio link and can be anything from simple
device configuration (a single FLASH block) to re-programming of the
entire device (first to serial EEPROM, then to FLASH once the EEPROM
image is verified). This process has worked thousands of times in
outdoor, harsh environments and over temperature extremes. I have
never seen a single problem that was found to be a FLASH error, and I
would know if there were because I would get an automatically
generated "CRC Fail" email from every device that did not program the
FLASH properly, or I would get a visit from a frowning manager if the
device stopped working after the FLASH upload.
Are you sure your hardware is okay? Ample power decoupling caps? Good
power during the erase/write cycles?
- Dave -
--- In m..., "Dan Muzzey" wrote: >
>
>
> >>>snip>>>
> What kind of problems have you had with FLASH? If you cannot trust it
> for data then you most certainly cannot trust it for program storage.
>
> >>>snip>>>
>
> I've never had a problem loosing programs. Then again, I use an
> external programmer to program the code. The MSP does not change the
> program with the FRAM. I would not trust the MSP to update its own
> program through some serial port.
>
> The only thing I can think of, and I am definitely not a chip designer
> (this is all a guess), is that the MSP is very susceptible to noise
> fluctuations on the power line when programming its own flash. Some
> lots are more susceptible than others. Every once in a while, a lot
> gets out that is really bad. The noise creates a marginal write to
> flash. Maybe this has something to do with the low power features of
> the chip. When TI designed the new chips they implemented a new feature
> to check for this marginal write to flash. But they screwed it up and
> it didn't work correctly. I've heard they have now fixed it but
the
> question remains. Why does the chip have to have a feature where it
> will check and make sure that it actually did what it was told to do? I
> would think that checking the contents of FLASH after a write would be
> more than adequate. Guess that might not be so. Imagine if the RAM
> worked the same way.
>
>
Reply by Dan Muzzey●November 17, 20082008-11-17
Just wondering...what is the work around? The way I understand the issues is
that the flash gets written to a level that reads as a 0 (or 1) but isn't
quite correct. It will still read correct, for awhile at least, but at some
time in the future it may flip. In order to work around this and still perform
the same function, you would need to find a way measure the voltage on the flash
location.
Am I missing something?
________________________________
From: m... [mailto:m...] On Behalf Of old_cow_yellow
Sent: Wednesday, November 12, 2008 10:12 PM
To: m...
Subject: [msp430] Re: MSP430 flash memory
Some F2xx devices have marginal Flash read modes too. Yes, there is a
bug, but I found a work-around and was able to test the Flash. Works
fine for me.
F5xx devices have the same marginal Flash read modes. I think the bug
is fixed but I did not try it.
--- In m... , "Dan Muzzey"
wrote: >
> Quick answer on the marginal flash....last I check there was an errata on it. Seems ti had a reason to put it in then managed to
screw it up putting it in. don't have the details at hand. Search
the errata. > -----Original Message-----
> From: m... on behalf of desertrc_tucson
> Sent: Wed 11/12/2008 3:41 PM
> To: m...
> Subject: [msp430] Re: MSP430 flash memory
>
> Yes, I agree there's not enough info to determine memory size.
>
> What kind of problems have you had with FLASH? If you cannot trust it
> for data then you most certainly cannot trust it for program storage.
>
> I have one product in customers hands that depends on FLASH data
> storage, and another on the way very soon. FLASH data is updated often
> in both cases. If there are issues with doing this I would be very
> interested in knowing what they are. I have not had a bit of trouble.
> Pun intended, sorry...
>
> BTW, the 54XX parts have built in tests for FLASH under marginal
> read conditions controlled by the FCTL4.MRG0 and FCTL4.MRG1 register
> bits. Has anyone ever tried this? Any failures?
>
> Thanks -
> Dave
>
> --- In m... , "Dan Muzzey"
wrote:
> >
> > Dave
> >
> > I'm not sure why you believe the requirements are outside the range.
> The requirements are to vague to come to that conclusion. We know
> that 500 bytes a day are needed. We know that the device has a life
> expectancy of 10 years. We do not know how many days of data is
> needed. If the entire life of the product is needed to be stored then
> it won't work. If you need 30 days worth then its doable.
> >
> > However, some people (myself included) have had trouble with the
> MSP430 internal flash. Others haven't had any problems. I would not
> recommend using it for data storage.
> >
> > ________________________________
> >
> > From: m... [mailto:m...
] On
> Behalf Of desertrc_tucson
> > Sent: Wednesday, November 12, 2008 9:54 AM
> > To: m...
> > Subject: [msp430] Re: MSP430 flash memory
> >
> > Your requirements are outside the address range, let alone FLASH
> > range, of the MSP430 family. You're wanting to write almost 2M-bytes
> > so whatever you use will have to be external. I would suggest a SD
> > FLASH memory card. See TI application note slaa281b for details on how
> > to do this. There is lots of example code out there on the Internet
> > for talking to the memory card.
> >
> > Regards -
> > Dave
> >
> > --- In m...
,
> Technical Kripa wrote:
> > >
> > > Should the flash memory in MSP430 be used only for downloading of
> > data or is it advisable to use flash memory for data logging
> > considering 100000 times writing capability of flash.
> > > In my current project I require to keep log of event at MSP ports. I
> > would have to write say approx 500bytes a day and the application is
> > supposed to work for around 10 years.
> > > Or should I use EEPROM or something else that one of you can suggest! > > >
> > >
> > > Cricket on your mind? Visit the ultimate cricket website.
> > Enter http://beta.cricket.yahoo.com
>
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
Reply by Dan Muzzey●November 17, 20082008-11-17
>>>snip>>> What kind of problems have you had with FLASH? If you cannot trust it
for data then you most certainly cannot trust it for program storage.
>>>snip>>>
I've never had a problem loosing programs. Then again, I use an
external programmer to program the code. The MSP does not change the
program with the FRAM. I would not trust the MSP to update its own
program through some serial port.
The only thing I can think of, and I am definitely not a chip designer
(this is all a guess), is that the MSP is very susceptible to noise
fluctuations on the power line when programming its own flash. Some
lots are more susceptible than others. Every once in a while, a lot
gets out that is really bad. The noise creates a marginal write to
flash. Maybe this has something to do with the low power features of
the chip. When TI designed the new chips they implemented a new feature
to check for this marginal write to flash. But they screwed it up and
it didn't work correctly. I've heard they have now fixed it but
the
question remains. Why does the chip have to have a feature where it
will check and make sure that it actually did what it was told to do? I
would think that checking the contents of FLASH after a write would be
more than adequate. Guess that might not be so. Imagine if the RAM
worked the same way.
Reply by Dan Muzzey●November 14, 20082008-11-14
Calculating the log of 5000 events is simple. 5000 X size of log event.
I will not use the internal flash to log data or store any parameters.
I've lost data while doing this and have had to add code to help deal with
this. Others have not had this problem yet at the same time no one can look at
the circuit and tell me for a fact what is wrong. Brown out circuits are in
place, extra by pass capacitance was added, simply put, other chips haven't
given us the same problems as the 449 has. I think the 149 is the same chip
minus the LCD.
As for the marginal write feature....why did TI have to put this in place in the
first place? If the flash write worked correctly there should be no need for
the chip to verify that it actually did what it was suppose to do and do it
correctly.
We have never had problems with chips that were programmed externally with a
programming tool. Its just the internal flash write that has given us
problems.
-----Original Message-----
From: m... on behalf of Technical Kripa
Sent: Thu 11/13/2008 12:59 AM
To: m...
Subject: Re: [msp430] Re: MSP430 flash memory
Thanksto all of you who replied...
I would explain the application which is quite basic....
I have 8 fire sensors connected to 8 ADC ports of MSP430F1x.
Set of output voltages of these sensors is as follows:
case 1: Fault condition (if sensor gets disconnected): Output of sensor/input to
ADC port = 0V-0.2V
case 2: Fault condition (if sensor terminals get shorted): Output of
sensor/input to ADC port = 3.0V-3.2V
case 3:Normal voltage output of sensor (no fire): Output of sensor/input to ADC
port = 2V-2.2V
case 4: Voltage output of sensor in case fire is detected/input to ADC port =
2.5-2.7V
I have to make a digitalport high (that drives a relay) in case of case 4 above
i.e. when fire is detected by any of the eight sensor. Addittionaly I have to
make a log of this event with time/date stamp. Last 30 days log would be
required. The data logging has to be FIFO
I also require to datalog fault conditions (case 1 & 2) with date/time stamp.
Case 3 requires no datalogging.
Probability of fault/fire condition is obviously very low (0-1000 times in 30
days). But I plan to keep datalogging for upto last 5000 events if possible.
Life of product is 10-15 years.
The flash has to store the program that consists of
1. The above logic
2. ADC program for 8 sensors
3. LCD display for status and time date display
4. small manipulations here and there
Now, let me know whether I should use flash memory or not. I can use MSP430F149
with 60KB flash.
If anyone can calculate and let me know how much flash space only datalogging of
5000 logsalone would take, I would appreciate.
Regards,
Sanmeet
________________________________
From: old_cow_yellow
To: m...
Sent: Thursday, 13 November, 2008 9:42:02 AM
Subject: [msp430] Re: MSP430 flash memory
Some F2xx devices have marginal Flash read modes too. Yes, there is a
bug, but I found a work-around and was able to test the Flash. Works
fine for me.
F5xx devices have the same marginal Flash read modes. I think the bug
is fixed but I did not try it.
--- In msp430@yahoogroups. com, "Dan Muzzey" wrote: >
> Quick answer on the marginal flash....last I check there was an errata on it. Seems ti had a reason to put it in then managed to
screw it up putting it in. don't have the details at hand. Search
the errata. > -----Original Message-----
> From: msp430@yahoogroups. com on behalf of desertrc_tucson
> Sent: Wed 11/12/2008 3:41 PM
> To: msp430@yahoogroups. com
> Subject: [msp430] Re: MSP430 flash memory
>
> Yes, I agree there's not enough info to determine memory size.
>
> What kind of problems have you had with FLASH? If you cannot trust it
> for data then you most certainly cannot trust it for program storage.
>
> I have one product in customers hands that depends on FLASH data
> storage, and another on the way very soon. FLASH data is updated often
> in both cases. If there are issues with doing this I would be very
> interested in knowing what they are. I have not had a bit of trouble.
> Pun intended, sorry....
>
> BTW, the 54XX parts have built in tests for FLASH under marginal
> read conditions controlled by the FCTL4.MRG0 and FCTL4.MRG1 register
> bits. Has anyone ever tried this? Any failures?
>
> Thanks -
> Dave
>
> --- In msp430@yahoogroups. com, "Dan Muzzey" wrote:
> >
> > Dave
> >
> > I'm not sure why you believe the requirements are outside the range.
> The requirements are to vague to come to that conclusion. We know
> that 500 bytes a day are needed. We know that the device has a life
> expectancy of 10 years. We do not know how many days of data is
> needed. If the entire life of the product is needed to be stored then
> it won't work. If you need 30 days worth then its doable.
> >
> > However, some people (myself included) have had trouble with the
> MSP430 internal flash. Others haven't had any problems. I would not
> recommend using it for data storage.
> >
> > ____________ _________ _________ __
> >
> > From: msp430@yahoogroups. com [mailto:msp430@yahoogroups. com] On
> Behalf Of desertrc_tucson
> > Sent: Wednesday, November 12, 2008 9:54 AM
> > To: msp430@yahoogroups. com
> > Subject: [msp430] Re: MSP430 flash memory
> >
> > Your requirements are outside the address range, let alone FLASH
> > range, of the MSP430 family. You're wanting to write almost 2M-bytes
> > so whatever you use will have to be external. I would suggest a SD
> > FLASH memory card. See TI application note slaa281b for details on how
> > to do this. There is lots of example code out there on the Internet
> > for talking to the memory card.
> >
> > Regards -
> > Dave
> >
> > --- In msp430@yahoogroups. com ,
> Technical Kripa wrote:
> > >
> > > Should the flash memory in MSP430 be used only for downloading of
> > data or is it advisable to use flash memory for data logging
> > considering 100000 times writing capability of flash.
> > > In my current project I require to keep log of event at MSP ports. I
> > would have to write say approx 500bytes a day and the application is
> > supposed to work for around 10 years.
> > > Or should I use EEPROM or something else that one of you can suggest! > > >
> > >
> > > Cricket on your mind? Visit the ultimate cricket website.
> > Enter http://beta. cricket.yahoo. com
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
