Disadvantages of MSP430 relative to AVR and PIC?

Un bel giorno Mr. C digit�:

> We had NUMEROUS problems writing to the flash reliably.

MSP430 flash has basically two problems:

1) You need to make sure that the internal charge pump frequency falls into
a certain range (which is also slightly different for the various
families). This means that you have to select which clock source to use
(ACLK, MCLK, etc..), calculate the right divider ratio and program the
appropriate flash register. This is annoying, especially if you use the DCO
and don't know exactly the operating frequency.

2) For reliable writes, you need at least a power supply of 2.7 V. In my
opinion this is the main issue; I can accept that below a certain voltage
the device can't work at its maximum frequency, but I expect at least that
every internal device will work flawlessy over the entire voltage range.


Just as a side note, MSP430 datasheets report in the absolute maximum
ratings a different storage temperature for programmed and unprogrammed
devices (-40/+85 and -55/+150 respectively). This doesn't make much sense:
a higher temperature could (and would) shorten the retention time of a
programmed device, but it wouldn't permanently damage it (which is the
meaning of the absolute maximum ratings): otherwise, it would permanently
damage also the unprogrammed device. I submitted to EPIC this observation
and they confirmed that this distinction is no longer valid, and will be
removed in the future datasheet revisions; the storage temperature will be
unified to -55/+150, whether the device is programmed or not.

> Those same parts are also VERY sensitive to any noise.

That's strange, I've used them without any problem in various applications
where they are *submersed* into noise!

-- 
emboliaschizoide.splinder.com

On Dec 17, 10:58=A0am, Mr. C <fakeem...@hotmail.com> wrote:
> On Tue, 16 Dec 2008 19:04:17 -0500, "MC"
>
> <for.address.l...@www.ai.uga.edu.slash.mc> wrote:
> >At risk of starting a religious war...
>
> >Why should I *not* prefer the MSP430 to the AVR and PIC?
>
> >Tell me its weak points.
>
> I have done several products using the MSP430, mostly the 'F149 and
> 'F449 parts. =A0Basically, except for a few special purpose
> applications, I will not use the MSP430 on future products. =A0We had
> NUMEROUS problems writing to the flash reliably. =A0The flash write
> problems have finally been somewhat acknowledged by TI, but they
> really have not solved the problems (maybe others parts in the MSP430
> family have them fixed).
>
> Those same parts are also VERY sensitive to any noise. =A0We do a pretty
> good job of board design and keeping our circuits immune from noise,
> but those parts were especially sensitive causing resets and, worst of
> all, lockups where even the watchdog timer would not pull it out.
>
> On the 'F44x parts, there were issues of sometimes not starting up
> when using a 32KHz crystal. =A0What is required is to properly "tune"
> the crystal used to the part. =A0We found the selection of capacitors
> for the crystal is very critical to starting up.
>
> I would not recommend using the 'F44x or 'F1xx parts for any
> applications but those that are battery powered and only applications
> that do NOT write to on-chip flash. =A0If I was forced to use an MSP430
> and I needed to write to non-volatile memory, I would use an external
> serial EEPROM or FRAM. =A0 In my career, I have used several micros, but
> the MSP430 family has definitely given me the most problems.
>
> Lou

Flash is the Achilles heel of every micro I have used, especially with
applications that write to it in the field.

>MSP430 flash has basically two problems:
>
>1) You need to make sure that the internal charge pump frequency falls into
>a certain range (which is also slightly different for the various
>families). This means that you have to select which clock source to use
>(ACLK, MCLK, etc..), calculate the right divider ratio and program the
>appropriate flash register. This is annoying, especially if you use the DCO
>and don't know exactly the operating frequency.

We were sure our flash frequency was correct.  Not the problem for us.

>2) For reliable writes, you need at least a power supply of 2.7 V. In my
>opinion this is the main issue; I can accept that below a certain voltage
>the device can't work at its maximum frequency, but I expect at least that
>every internal device will work flawlessy over the entire voltage range.

Yep, we had good programming voltage too.  One observation we had is
that once you programmed flash, there is no guarantee (without
verification) that the contents are correct.  So, to take care of
that, you need to read back what you programmed and make sure it got
programmed correctly.

Also, see their document slaa334.pdf, section 3.3, where it gives
strange warnings like, "Each time a single bit, byte, or word is
programmed, a complete row of 64-byte flash cells sees the high
voltage necessary for programming. This high voltage generates some
stress to the complete row of flash cells, and this stress must be
time limited to avoid damage. The next erase cycle resets this stress
time to zero, and the cumulative program time restarts again from the
beginning. According to the data sheet, as shown in Table 3, this
high-voltage stress must be limited to 10 ms between two erase cycles.
See the data sheets for the correct values for each MSP430
derivative."  Why would they have such a strange write-up if their
flash was not fragile?

What is especially discouraging is when the same document (section
4.2) goes on to say, "As explained in the previous section, data
retention time is very much dependent on the ambient temperature of
the MSP430 application. One possible solution to enhance flash data
retention is refreshing the flash contents from time to time with
software." (!)  In other words, make good in firmware what we somehow
couldn't seem to get right in hardware.

The place the MSP430 really shines, and the thing TI promotes the most
about it is its super low current drain.  With a 16-bit core that
includes multiply and divide instructions, you have a LOT of compute
power, yet can achieve a very low current drain.  For our
battery-operated products that used the MSP430, it seemed to be great.
(There, I said something good about the MSP430 :-) )  In almost ALL
their example circuits, they show the MSP430 being battery powered.  I
think that is what the processor was primarily designed for.  And I
sometimes wonder if they didn't compromise other things to get there.

>> Those same parts are also VERY sensitive to any noise.
>
>That's strange, I've used them without any problem in various applications
>where they are *submersed* into noise!

We found that battery operated applications fared much better than the
power supply applications.  I don't know why, but the MSP430 was
definitely the most sensitive processor I have ever worked with.  Just
my experience.

Lou

>Flash is the Achilles heel of every micro I have used, especially with
>applications that write to it in the field.

I have pretty much decided that any application that requires storage
to non-volatile memory will use some sort of off-chip serial memory
like an EEPROM for limited writes, or an FRAM for unlimited writes.
Defintely gives me peace of mind.

Lou

On Dec 17, 2:18 pm, steve <bungalow_st...@yahoo.com> wrote:
> On Dec 17, 10:58 am, Mr. C <fakeem...@hotmail.com> wrote:
>
>
>
> > On Tue, 16 Dec 2008 19:04:17 -0500, "MC"
>
> > <for.address.l...@www.ai.uga.edu.slash.mc> wrote:
> > >At risk of starting a religious war...
>
> > >Why should I *not* prefer the MSP430 to the AVR and PIC?
>
> > >Tell me its weak points.
>
> > I have done several products using the MSP430, mostly the 'F149 and
> > 'F449 parts.  Basically, except for a few special purpose
> > applications, I will not use the MSP430 on future products.  We had
> > NUMEROUS problems writing to the flash reliably.  The flash write
> > problems have finally been somewhat acknowledged by TI, but they
> > really have not solved the problems (maybe others parts in the MSP430
> > family have them fixed).
>
> > Those same parts are also VERY sensitive to any noise.  We do a pretty
> > good job of board design and keeping our circuits immune from noise,
> > but those parts were especially sensitive causing resets and, worst of
> > all, lockups where even the watchdog timer would not pull it out.
>
> > On the 'F44x parts, there were issues of sometimes not starting up
> > when using a 32KHz crystal.  What is required is to properly "tune"
> > the crystal used to the part.  We found the selection of capacitors
> > for the crystal is very critical to starting up.
>
> > I would not recommend using the 'F44x or 'F1xx parts for any
> > applications but those that are battery powered and only applications
> > that do NOT write to on-chip flash.  If I was forced to use an MSP430
> > and I needed to write to non-volatile memory, I would use an external
> > serial EEPROM or FRAM.   In my career, I have used several micros, but
> > the MSP430 family has definitely given me the most problems.
>
> > Lou
>
> Flash is the Achilles heel of every micro I have used, especially with
> applications that write to it in the field.

Flash is great for developments and avr is nice for prototypes.
However, we are looking into two other non-flash uC for productions.
Avr and msp are too expensive.  Pic is too ugly.

Un bel giorno Mr. C digit�:

> What is especially discouraging is when the same document (section
> 4.2) goes on to say, "As explained in the previous section, data
> retention time is very much dependent on the ambient temperature of
> the MSP430 application. One possible solution to enhance flash data
> retention is refreshing the flash contents from time to time with
> software." (!)  In other words, make good in firmware what we somehow
> couldn't seem to get right in hardware.

Well, you can't blame them for the adversities of the laws of physics. ;-)

The dependence of data retention time on temperature (mostly driven by
thermal agitation) is pretty much the same for every flash cell; you can
roughly assume that for every 10 �C temperature raise, the retention time
will halve. This is explained in slaa334a that you've quoted, and even
better in slaa392:

http://focus.ti.com/mcu/docs/mcusupporttechdocsc.tsp?sectionId=96&tabId=1502&abstractName=slaa392

What changes from a flash to another, of course, is the "base line": for
the MSP430 they have specified the typical retention time at the room
temperature, not over the entire working/storage range. A data retention of
100 years at 25 �C corresponds to barely two years at 85 �C (working
limit), and one week at 150 �C (storage limit). It makes you think. :)

The fact that MCU program flashes are lousy is not news; since this thread
started as a MSP-AVR comparison, it's interesting to point out that Atmel
doesn't even bother to specify the flash retention time in its
ATtiny/ATmega datasheets (yes, I'm sure it's reported in some app note, but
still...).

>>> Those same parts are also VERY sensitive to any noise.
>>
>>That's strange, I've used them without any problem in various applications
>>where they are *submersed* into noise!
> 
> We found that battery operated applications fared much better than the
> power supply applications.  I don't know why, but the MSP430 was
> definitely the most sensitive processor I have ever worked with.  Just
> my experience.

I thought you were referring to radiated noise. On conducted noise,
actually, I had some problems too but only with the JTAG low-cost interface
(MSP-FET430UIF). It seems very sensible to noise on the power source of the
target, and in several devices I've been forced to put a blocking diode and
a capacitor on the JTAG Vcc signal.

-- 
emboliaschizoide.splinder.com

In article <antik41666g2eobbtt7o9afo7e3945hbkr@4ax.com>, 
fakeemail@hotmail.com says...
> >MSP430 flash has basically two problems:
> >
> >1) You need to make sure that the internal charge pump frequency falls into
> >a certain range (which is also slightly different for the various
> >families). This means that you have to select which clock source to use
> >(ACLK, MCLK, etc..), calculate the right divider ratio and program the
> >appropriate flash register. This is annoying, especially if you use the DCO
> >and don't know exactly the operating frequency.
> 
> We were sure our flash frequency was correct.  Not the problem for us.
> 
> >2) For reliable writes, you need at least a power supply of 2.7 V. In my
> >opinion this is the main issue; I can accept that below a certain voltage
> >the device can't work at its maximum frequency, but I expect at least that
> >every internal device will work flawlessy over the entire voltage range.
> 
> Yep, we had good programming voltage too.  One observation we had is
> that once you programmed flash, there is no guarantee (without
> verification) that the contents are correct.  So, to take care of
> that, you need to read back what you programmed and make sure it got
> programmed correctly.
> 
> Also, see their document slaa334.pdf, section 3.3, where it gives
> strange warnings like, "Each time a single bit, byte, or word is
> programmed, a complete row of 64-byte flash cells sees the high
> voltage necessary for programming. This high voltage generates some
> stress to the complete row of flash cells, and this stress must be
> time limited to avoid damage. The next erase cycle resets this stress
> time to zero, and the cumulative program time restarts again from the
> beginning. According to the data sheet, as shown in Table 3, this
> high-voltage stress must be limited to 10 ms between two erase cycles.
> See the data sheets for the correct values for each MSP430
> derivative."  Why would they have such a strange write-up if their
> flash was not fragile?
> 
> What is especially discouraging is when the same document (section
> 4.2) goes on to say, "As explained in the previous section, data
> retention time is very much dependent on the ambient temperature of
> the MSP430 application. One possible solution to enhance flash data
> retention is refreshing the flash contents from time to time with
> software." (!)  In other words, make good in firmware what we somehow
> couldn't seem to get right in hardware.
> 
> The place the MSP430 really shines, and the thing TI promotes the most
> about it is its super low current drain.  With a 16-bit core that
> includes multiply and divide instructions, you have a LOT of compute
> power, yet can achieve a very low current drain.  For our
> battery-operated products that used the MSP430, it seemed to be great.
> (There, I said something good about the MSP430 :-) )  In almost ALL
> their example circuits, they show the MSP430 being battery powered.  I
> think that is what the processor was primarily designed for.  And I
> sometimes wonder if they didn't compromise other things to get there.

I think they made a compromise you missed:  None of the MSP430
variants that I have used include a divide instruction.  They
have integer multiply and MAC hardware, but no divide.
> 
> >> Those same parts are also VERY sensitive to any noise.
> >
> >That's strange, I've used them without any problem in various applications
> >where they are *submersed* into noise!
> 
> We found that battery operated applications fared much better than the
> power supply applications.  I don't know why, but the MSP430 was
> definitely the most sensitive processor I have ever worked with.  Just
> my experience.
> 

Mark Borgerson

>I think they made a compromise you missed:  None of the MSP430
>variants that I have used include a divide instruction.  They
>have integer multiply and MAC hardware, but no divide.

I guess it's obviously been a while since I used it :-)  Thanks for
the correction.

Lou

MC wrote:

> At risk of starting a religious war...
> Why should I *not* prefer the MSP430 to the AVR and PIC?
> Tell me its weak points.

In quite many practical cases, the 5V I/O and supply are required. 
MSP430 is 3.3V only.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

On Dec 17, 5:45=A0am, John Devereux <j...@devereux.me.uk> wrote:

> The main problem I had with the AVR's (for "bigger" applications in
> C), is the contortions you have to go through to access constant data
> in flash. It has a "harvard" architecture, meaning you need a

Am I missing something here? The AVR compilers I've used seem to hide
this fact from the developer quite successfully (as compared to, say,
the PIC compilers, which are of course simply an exercise in
futility).