Disadvantages of MSP430 relative to AVR and PIC?
in [Embedded]
|
Prev: 16C752 Problem
Next: MAX3421E to PIC18F4550
From: dalai lamah on 17 Dec 2008 14:59 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
From: steve on 17 Dec 2008 17:18 On Dec 17, 10:58 am, Mr. C <fakeem...(a)hotmail.com> wrote: > On Tue, 16 Dec 2008 19:04:17 -0500, "MC" > > <for.address.l...(a)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.
From: Mr. C on 17 Dec 2008 17:27 >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
From: Mr. C on 17 Dec 2008 17:31 >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
From: linnix on 17 Dec 2008 18:22
On Dec 17, 2:18 pm, steve <bungalow_st...(a)yahoo.com> wrote: > On Dec 17, 10:58 am, Mr. C <fakeem...(a)hotmail.com> wrote: > > > > > On Tue, 16 Dec 2008 19:04:17 -0500, "MC" > > > <for.address.l...(a)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. |