Hi,

I'm trying to use MSP430 in a line of industrial sensors. But the
programmer says:

"My biggest issue with the MSP is its inability to lock the program
memory. This is a very big shortcoming in the MSP series.

Brownout protection is not a guarantee. It's a patch on a known
problem that I have seen repeatedly in very noisy environments.

SoftBaugh's Tom Baugh, who is probably one of the most knowledgable
guys on the MSP430 outside of TI, can't seem to avoid losing flash."

In my uP experience with earlier devices with external memory, a tiny
uS glitch, not enough to damage the hardware, could couple to, say, a
memory address bit that caused the uP to access an incorrect
location. If this was a program access, the uP could execute data and
trash flash program storage. I'm not sure if internal-flash devices
have similar issues, but forinstance a glitch coupled to the clock
pins could result in an out-of-spec clock cycle that could cause the
same havoc.

The programmer wants a way to "lock the program memory" so this is
very unlikely to happen. Apparently PIC offers this feature???

Brown-out may cause a similar problem, as we're running at 12MHz and
will be out of spec when the brown out circuit resets the uP at 1.8V.
Seems that to protect the program memory we'd need a brown-out
threshold detector that's suitable for 12MHz, ~3V.

If a zap or brownout causes bad software execution without changing
program storage in flash, we don't care, the watchdog gets us back on
track. But if there's no ironclad protection for program flash, we're
toast.

Help!

...Larry
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Your programmer doesn't know the MSP430 then does he? Flash can be
locked as in protected from snooping as good as most non-high security
micros, and is always locked agains inadvertent programming. The
sequence to enable self programming is complex enough to make it highly
unlikely. A browwnout during a flash write MIGHT cause erroneous
programming, but any good flash self programing code would have self
test and verify built into it. I don't know why Tom might be losing
Flash, were I flippant i'd say damned careless of him! I have customer
designs that have shipped in very large volumes over the last 9-10 years
and have no instance of flash corruption in the field that was not
caused by stupidity. (ie customer connecting to high voltage or welding
on the equipment)

other than when Flash endurance testing at extremes of voltage and
temperature, or age I have never 'lost' a flash memory.

If a read from an illegal flash address takes place the Flash access
violation interrupt is there to handle it. providedyour code is well
written, and your hardware well designed I see no reason to worry about
the integrity of the MSP430 flash.

Sounds like your progammer is a PIC guy, since he obviously has never
read the MSP430 user guides, or studied what it takes to self write
flash on the MSP, and it sounds like he wants to push you to his comfort
zone.

Al

lksjofiheohtnela wrote:

>Hi,
>
>I'm trying to use MSP430 in a line of industrial sensors. But the
>programmer says:
>
>"My biggest issue with the MSP is its inability to lock the program
>memory. This is a very big shortcoming in the MSP series.
>
>Brownout protection is not a guarantee. It's a patch on a known
>problem that I have seen repeatedly in very noisy environments.
>
>SoftBaugh's Tom Baugh, who is probably one of the most knowledgable
>guys on the MSP430 outside of TI, can't seem to avoid losing flash."
>
>In my uP experience with earlier devices with external memory, a tiny
>uS glitch, not enough to damage the hardware, could couple to, say, a
> memory address bit that caused the uP to access an incorrect
>location. If this was a program access, the uP could execute data and
>trash flash program storage. I'm not sure if internal-flash devices
>have similar issues, but forinstance a glitch coupled to the clock
>pins could result in an out-of-spec clock cycle that could cause the
>same havoc.
>
>The programmer wants a way to "lock the program memory" so this is
>very unlikely to happen. Apparently PIC offers this feature???
>
>Brown-out may cause a similar problem, as we're running at 12MHz and
>will be out of spec when the brown out circuit resets the uP at 1.8V.
>Seems that to protect the program memory we'd need a brown-out
>threshold detector that's suitable for 12MHz, ~3V.
>
>If a zap or brownout causes bad software execution without changing
>program storage in flash, we don't care, the watchdog gets us back on
>track. But if there's no ironclad protection for program flash, we're
>toast.
>
>Help!
>
>...Larry
>------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Sounds like your guy really doesnt know the msp series.. It takes a special=
sequence to enable programming, so I can't see it being done by mistake..=
=20
By default the flash IS locked.
I know of no flash failures in devices that I produced and of those I know =
of others have produced..
=A0
Sounds like he is a pic guy and does want to work out of his confort zone (=
seems to be fairly common with pic guys as many seem to only want to stay w=
ithin that line.. I don't know why).. Personally I feel use the product bes=
t suited for the job and sounds like its time to look for a better rounded =
programmer..
=A0
As to brownouts, any flash routines worth their while should be testing the=
ir writes afterwards.. If your design is that suseptable to brownouts, it s=
eeems as if you need some work on it.. The MSP series can wite successfully=
at some pretty low voltages and high operating speeds and even lower when =
you slow the clock down..
=A0
You don;t need an external brownout detector, just choose a part with svs..=
or go to the 5xx series which has some serious built in voltage regulation=
..
=A0
Just about any microcontroller can be screwed up if the voltage drops durin=
g a write, so its something that a good designer plans for.. personally whe=
n I have to do flash writes , I disable all unnecessary actions, with just =
a flash write the voltage/current needs are small and some good caps on the=
supply lines should eliminate any issues you might see..
=A0
=A0
--- On Mon, 8/25/08, lksjofiheohtnela wrote:

From: lksjofiheohtnela
Subject: [msp430] Locking program memory
To: m...@yahoogroups.com
Date: Monday, August 25, 2008, 11:52 AM

Hi,

I'm trying to use MSP430 in a line of industrial sensors. But the
programmer says:

"My biggest issue with the MSP is its inability to lock the program
memory. This is a very big shortcoming in the MSP series.

Brownout protection is not a guarantee. It's a patch on a known
problem that I have seen repeatedly in very noisy environments.

SoftBaugh's Tom Baugh, who is probably one of the most knowledgable
guys on the MSP430 outside of TI, can't seem to avoid losing flash."

In my uP experience with earlier devices with external memory, a tiny
uS glitch, not enough to damage the hardware, could couple to, say, a
memory address bit that caused the uP to access an incorrect
location. If this was a program access, the uP could execute data and
trash flash program storage. I'm not sure if internal-flash devices
have similar issues, but forinstance a glitch coupled to the clock
pins could result in an out-of-spec clock cycle that could cause the
same havoc.

The programmer wants a way to "lock the program memory" so this is
very unlikely to happen. Apparently PIC offers this feature???

Brown-out may cause a similar problem, as we're running at 12MHz and
will be out of spec when the brown out circuit resets the uP at 1.8V.
Seems that to protect the program memory we'd need a brown-out
threshold detector that's suitable for 12MHz, ~3V.

If a zap or brownout causes bad software execution without changing
program storage in flash, we don't care, the watchdog gets us back on
track. But if there's no ironclad protection for program flash, we're
toast.

Help!

...Larry

=20

[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Larry,

Thanks for the email asking for clarification from our perspective.
Since we are a TI NDA holder, I must necessarily be discreet and not
reveal any of TI's intellectual property. But, I can discuss our
experiences by wearing the hat of an MSP430 user for a decade now.

1. Our USBP/USBPPRO, which uses an F135 or F155, depending on the
version, does from time to time lose data in the program flash.
>From the support calls we have had about this, most of these cases
can be traced to ESD or ground loops that arise in the course of
normal lab work. Others are more mysterious, but probably are
unwittingly similar. After reviewing our customers' ESD plans, only
a few suffer additional failures.

2. We have designed the USBP/USBPPRO such that this circumstance,
either in that the memory check fails, or if the memory check itself
is corrupted, is a "mission kill" in that we want these units
returned to us for testing. Some kills are obvious enough that we
just tell the customer over the phone that the unit went bye-bye, but
others we bring back to our lab, reprogram them and then run our
quality tests on the unit before returning them to the customer.
What we don't want happening is for a unit to suffer an ESD hit or a
ground loop and then attempt to repair itself without a chance to see
what else may have suffered in the process. We think this is the
safest course of action, particularly since many of our customers are
programming large numbers of devices with them.

3. At this point, in new designs we would avoid using the MSP430
flash to store ad-hoc data. Instead, we prefer to design in an
external serial flash and use that. Some applications cannot
tolerate the additional cost, but that is our position :-(

4. You will notice no MSP430X or F5xx boards on our website. We
decided early in the lifecycle of the MSP430X parts to not recommend
them, and so we don't make eval boards for them. We've come to the
same conclusion about the F5xx. A forthcoming book due in a month or
so will explain some of our reasons in detail for avoiding these
subfamilies.

5. Our USBP/USBPPRO/UBSL/REP430 pages specifically mention that we
would rather you not use any of our programmers for the MSP430X or
F5xx parts. Essentially, if you have problems with those parts, we
don't want to get that support call.

6. You mentioned industrial sensors. I would review your
requirements to find out whether an MSP430 is the best choice for
that specific application. Again, our forthcoming book provides
additional detail about how to make this decision, but here is a
teaser in a recent press release:

http://research.tdameritrade.com/public/stocks/news/story.asp?
docKey=100-226p4040-1&searchCategory=latest

If that link doesn't work, get a quote search for TXN from any major
discount brokerage (no account required), then look at the news
articles from 13 Aug 2008.

Disclaimers:

Our recommendations of whether or not to use the MPS430X or F5xx
parts in your design are based on our experience with the parts, and
do not imply that we are making a recommendation based on "secret"
NDA knowledge. In this next book we give our rationale based on
publically available information about the MSP430X and the F5xx.

Our decision to explicitly not support the MSP430X or F5xx parts is
based on all the information at our disposal as a tools vendor in
order to maximize the return on investment of resources, and does not
necessarily imply any fault by any party.

Tom
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Tom,
I am designing with MSP430 series for 7 years and I have not noticed the pr=
oblems you mentioned.
ESD, EMC and ground loops are all design issues. My industrial grade design=
s stands to 50KV ESD (not HBM that would be far easier), 2.5KV EMC and grou=
nd loops cannot affect equipment functions (but, of course, can affect sign=
al integrity). In one particular design the FLASH memory is often erased/wr=
itten and I never had any failure even under repetitive ESD strikes. Of cou=
rse there were times the equipment did reset but it didn't loose FLASH cont=
ents. When a write operation was broken because the reset it later did chec=
k the contents and attempt to write again, writing in another area a time s=
tamp so engineers could retrieve what and when it did happen.
Regarding the X family I have been using the F2618 for a while in the same =
harsh environment and no failures or hiccups have been noticed. It is, inde=
ed, a nice advancement in the MSP430 family.
Of course, this endurance is not a particular feature of MSP430 devices. An=
y uC can stand well when the whole design is done thoroughly.
I am not saying your (or Larry's) design is poor but specific knowledge is =
the key to solve some real world issues as Joerg, All and many others here =
have shown.
Perhaps you could hire engineering services (me?) to help avoid with the re=
maining issues you have seen in some products.
BR
-Augusto

De:m...@yahoogroups.com

Para:m...@yahoogroups.com

C=F3pia:

Data:Tue, 26 Aug 2008 02:18:13 -0000

Assunto:[msp430] Re: Locking program memory

Larry,

Thanks for the email asking for clarification from our perspective.=20
Since we are a TI NDA holder, I must necessarily be discreet and not=20
reveal any of TI's intellectual property. But, I can discuss our=20
experiences by wearing the hat of an MSP430 user for a decade now.

1. Our USBP/USBPPRO, which uses an F135 or F155, depending on the=20
version, does from time to time lose data in the program flash.=20
>From the support calls we have had about this, most of these cases=20
can be traced to ESD or ground loops that arise in the course of=20
normal lab work. Others are more mysterious, but probably are=20
unwittingly similar. After reviewing our customers' ESD plans, only=20
a few suffer additional failures.

2. We have designed the USBP/USBPPRO such that this circumstance,=20
either in that the memory check fails, or if the memory check itself=20
is corrupted, is a "mission kill" in that we want these units=20
returned to us for testing. Some kills are obvious enough that we=20
just tell the customer over the phone that the unit went bye-bye, but=20
others we bring back to our lab, reprogram them and then run our=20
quality tests on the unit before returning them to the customer.=20
What we don't want happening is for a unit to suffer an ESD hit or a=20
ground loop and then attempt to repair itself without a chance to see=20
what else may have suffered in the process. We think this is the=20
safest course of action, particularly since many of our customers are=20
programming large numbers of devices with them.

3. At this point, in new designs we would avoid using the MSP430=20
flash to store ad-hoc data. Instead, we prefer to design in an=20
external serial flash and use that. Some applications cannot=20
tolerate the additional cost, but that is our position :-(

4. You will notice no MSP430X or F5xx boards on our website. We=20
decided early in the lifecycle of the MSP430X parts to not recommend=20
them, and so we don't make eval boards for them. We've come to the=20
same conclusion about the F5xx. A forthcoming book due in a month or=20
so will explain some of our reasons in detail for avoiding these=20
subfamilies.

5. Our USBP/USBPPRO/UBSL/REP430 pages specifically mention that we=20
would rather you not use any of our programmers for the MSP430X or=20
F5xx parts. Essentially, if you have problems with those parts, we=20
don't want to get that support call.

6. You mentioned industrial sensors. I would review your=20
requirements to find out whether an MSP430 is the best choice for=20
that specific application. Again, our forthcoming book provides=20
additional detail about how to make this decision, but here is a=20
teaser in a recent press release:

http://research.tdameritrade.com/public/stocks/news/story.asp?
docKey=3D100-226p4040-1&searchCategory=3Dlatest

If that link doesn't work, get a quote search for TXN from any major=20
discount brokerage (no account required), then look at the news=20
articles from 13 Aug 2008.

Disclaimers:

Our recommendations of whether or not to use the MPS430X or F5xx=20
parts in your design are based on our experience with the parts, and=20
do not imply that we are making a recommendation based on "secret"=20
NDA knowledge. In this next book we give our rationale based on=20
publically available information about the MSP430X and the F5xx.

Our decision to explicitly not support the MSP430X or F5xx parts is=20
based on all the information at our disposal as a tools vendor in=20
order to maximize the return on investment of resources, and does not=20
necessarily imply any fault by any party.

Tom
=20
[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

"Tom Baugh" :

> 3. At this point, in new designs we would avoid using the MSP430
> flash to store ad-hoc data. Instead, we prefer to design in an
> external serial flash and use that. Some applications cannot
> tolerate the additional cost, but that is our position :-(

Interesting. We had big problems with external Flash (I2C-EEPROMS) and ESD
strokes in the past (30kV discharges from the TV-tube). The ESD stroke can
couple into the data and clock lines to the chip and/or is producing a VCC
drop or rise and can influence the crystal of your controller (and the
controller clock).
With the internal MSP430 flash you only have the VCC/crystal problem left!?
My guess would be that you have lesser problems with flash inside the
controller.

> 4. You will notice no MSP430X or F5xx boards on our website. We
> decided early in the lifecycle of the MSP430X parts to not recommend
> them, and so we don't make eval boards for them. We've come to the
> same conclusion about the F5xx. A forthcoming book due in a month or
> so will explain some of our reasons in detail for avoiding these
> subfamilies.

MSPX have a segmented memory space - like the old 8086 or others. Well Arm7
with linear 32bit address space is much more comfortable. :-) (and it seems
that are still many JTAG (debug/program) bugs, but this will probably be
solved in the future?)

M.
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

2008/8/28 Matthias Weingart

> "Tom Baugh" :
>
> > 3. At this point, in new designs we would avoid using the MSP430
> > flash to store ad-hoc data. Instead, we prefer to design in an
> > external serial flash and use that. Some applications cannot
> > tolerate the additional cost, but that is our position :-(
>
> Interesting. We had big problems with external Flash (I2C-EEPROMS) and ESD
> strokes in the past (30kV discharges from the TV-tube). The ESD stroke can
> couple into the data and clock lines to the chip and/or is producing a VCC
> drop or rise and can influence the crystal of your controller (and the
> controller clock).
> With the internal MSP430 flash you only have the VCC/crystal problem left!?
> My guess would be that you have lesser problems with flash inside the
> controller.
>

I use a combination of both external and internal flash storage. The
firmware has a long pedigree, starting out on F148 and migrating through
F149, F2418 and F5438 devices. I have not had problems with the
configuration data being lost from the internal flash as I always verify
that the write has been successful before continuing.
> > 4. You will notice no MSP430X or F5xx boards on our website. We
> > decided early in the lifecycle of the MSP430X parts to not recommend
> > them, and so we don't make eval boards for them. We've come to the
> > same conclusion about the F5xx. A forthcoming book due in a month or
> > so will explain some of our reasons in detail for avoiding these
> > subfamilies.
>
> MSPX have a segmented memory space - like the old 8086 or others. Well Arm7
> with linear 32bit address space is much more comfortable. :-) (and it seems
> that are still many JTAG (debug/program) bugs, but this will probably be
> solved in the future?)
>
> M.
>
> I have found the 430X parts to work well. I have a working product based
on the prototype F5438 using this same ported code. The changes required
were minimal, around 3-4 days work to get the 60K application to run on the
new processor - mostly serial ports and interrupt changes. As far as the
reported bugs are concerned - these have not been a problem, just read the
errata sheet. A couple of compiler bugs have made life interesting but
these have been fixed.

The really nice thing about the 5x series is the price. 2/3 the cost of an
F149 for a device with vastly more memory and more peripherals.

I do not understand your comment about the address being like 8086. I
cannot see any resemblance at all. There is no segment/offset register pair
to generate the address as used on the x86 architecture. Top me the address
space looks like a linear 24 bit address range.

Ian
[Non-text portions of this message have been removed]
------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Matthias Weingart wrote:
> MSPX have a segmented memory space - like the old 8086 or others.
> Well Arm7 with linear 32bit address space is much more comfortable. :-)

Ian Okey wrote:
> I do not understand your comment about the address being like 8086. I
> cannot see any resemblance at all. There is no segment/offset register pair
> to generate the address as used on the x86 architecture. Top me the address
> space looks like a linear 24 bit address range.

Hi Ian and Matthias, and the rest of you.

The MSP430X do have a kind of segment, it does a wrap-around around
64KB. However, the interrupt vector table is always placed at the top of
the 64KB area, this prevents a normal object to span across this border
so normal code does not have to handle this.

In fact, the simple segmentation used in the MSP430X is quite elegant as
it allows access to either the lower 64KB or the entire memory range
with basically the same instruction set and registers.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )