This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430F55xx

Other Parts Discussed in Thread: MSP430F5508, TPS61221

I am developing a battery powered application where i will need a RTC, one UART, one I2C and one SPI, and couple ADC. Looking at MSP430 devices both that seems to suit to my applications are the MSP430F55xx/53xx series and FRAM devices. As my dutycycle will be something from 1/000 and down (probably 1/10000 sometimes) i belive the FRAM device is not the most suitable due to its high LPM3 current consumption compared to the flash family. Is that correct or i missed something here?

Finally, my application won't need much processing power, basically just a datalogger reading a few sensors and writing on an external flash. I belive a few AVR devices could handle that and have the same peripherals. Is there any power consumption comparison betwen AVRmega devices and the MSP430F55xx family?

Thank you! 

  • First sorry about the thread title. I just noticed that i forgot to write "doubts".

    I have a few extra questions regarding the same device. I will probably be  using a MSP430F5508 device clocking it with a watch crystal. However, reading several topics about MSP430 clock configuration i got confused. 

    Let me first explain my situation. My system should behave as following. It will be a CR2032 battery powered data logger with the size of a watch. I will have a few sensors and an external SPI flash. It should be configurable to sample all the sensors from 1s to 5min interval. So it will remain at low power mode during that interval. After that the microcontroller will powerup the SPI flash sample the sensors (connected on a I2C bus), write on the flash the date and time of sample with the sapled data and get back to sleep. There will be a serial connector to pull the data out from the device. 

    My doubt is about the clock generation with the DCO. As i will be talking with all the external devices (sensors and flash) usign SPI and I2C, a higher clock would be suitable. If a create a higher clock using FLL i belive i wont have problems as they are sychronous communications. However several threads are talking about a problem on using UART with high Baud Rate clocked by DCO. As i will be using a 32Khz external clock, is there any way to create a stable and precise higher frequency inside the MSP430 so i can work with higher baud rates. Is it suitable to generate such higher frequency when sampling sensos and writing flash or there is some ultral high current consumption that i am not considering?

    Finally, i was looking at the User Manual and could not find where the clock division takes place so i can get a 1hz clock from a 32.768kHz at my RTC_A module. 

    Thank you!

  • After reading more and more i got an idea of operation. First off all, if i use FLL the wake-up time will be very high (compared to the 5us) right? So the idea is to just turn FLL on when i will pull the data out. On the normal sensor sampling mode i can just turn DCO on as i wont need much accuracy at my clock. Considering that my idea is valid, which is the proper way to wake-up using UART? Lets consider a 115200 baud rate. Should i set my UART for 9600 bps and them after FLL is stable switch to higher baud rate? According to User Manual it is possible to run a 9600 bps from a 32768 Hz crystal. Is that correct?


    Thank you!

  • As i am not getting any answer here i belive the reason is due to my thread title. Should i create a new thread with a better title? Or the reason is that my explanation is confusing? Or maybe i am unlucky. 

    Thank you!

  • Luis Filipe Rossi said:
    As i am not getting any answer here i belive the reason is due to my thread title.

    Well, the thread title doesn't say anything, but also, your problem seems to be complex (or at least the large block of text makes this impression). So many people may simply skip it.

    Even for me, threads which look complex are postponed until either someone else answers or I find the time to dive deeper into it. Except for a few, most of us here do this in our spare time. And personally, I prefer helping ten people with their smaller problems than one with a big one (or at least that seems to be big on first glance). Except if I find the problem challenging. But to do so, i have to read the thread first :)

    However, your description of your problems/questions is indeed a bit unclear.

    I'm trying to answer a few:

    I don't think you can compare the ATMega with the MSP in terms of power consumption. It always depends on what you're doing. You can dynamically clock down the MSP if you don't need the CPU power all teh time. You can send it to sleep if you don't need it for longer periods of time. You can disable all components you don't need and they won't consume any power. If you don't do this, well, the MSP can consume as much or more power than the ATMega. So comparison charts are pretty much useless for anything than advertizing. You can go much lower with the MSP while you can have more CPU power (but not at the same time). But it depends on your skills how much you can achieve (for both extremes).

    What do you mean with duty cyle down to 1/10000. Does it mean you have a puls/pause of 1:9999 or a PWM frequency of 1/10000 second?

    Well both can be done with the MSP (any of the mentioned) easily. When clocking a timer with 8MHz, you can have a duty cycle resolution of 1/10000 of a PWM cycle with a frequency of 800Hz or less. Simple math: resolutioj is one timr tick, so a resolution of 1/10000 means you need a cycle length of at least 10000 timer ticks.

    You are partly right about the power consumption of FR and F deices. The FR requires a little higher operating current (and beyond 8MHz it is less efficient due to FRAM waitstates) but teh larger fetch cache easses thsi a bit. The FR devices excel if you have data that needs to be stored, as storing data in FRAM doesn't take more time or current than reading it. here flash is by magnitudes worse. Also, if you run your code in ram, the FRAM devices go significantly down with the operating current.

    Also, since FRAM is non-volatile, you can build devices which are powered by a keyboard event rather than waiting for a keyboard interrupt. Since all data is retained, teh device will still remember its last state even if it is not powered at all in-between. zero power consumption.

    It depends on your application.

    p.s.: if you don't need the USB controller, you should rather look at the 54xxA devices.

    About the DCO, well, indeed the DCO is somewhat unprecise. You cannot jsut say 'I want thsi frequency'. The required settigns to get this frequency or at least near it, are different for every MSP. Thsi is where the FLL kicks in. It can adjust the DCO until it runs synchronous (as much as possible) to to a precise external low-frequency source. This takes some time (milliseconds, not minutes). The FLL will also detect and compensate for long-time drift. However, uising the FLL during a short wakeup is counterproductive: Uing the FLL doesn't increase the wakeup time. But once the DCO is enabled again, the FLL requires some time before the DCO is properly adjusted again (the electronics will have drifted during the off time). It makes no sense enabling the FLL if less than a few reference clock cycles pass before the device goes back to sleep. The CPU will start executing after 6µs in any case. Only the exact CPU frequency is uncertain.

    The FR devices have an eUSCI that allows an interrupt when a start bit is detected. So on low baudrate there is some time to settle the DCO before the bit length must eb accurate (you can always wait as long as you need before you start sending). However, the MSP is a bit more tolerant to wrong baudrate when receiving.

    Nevertheless, having the required level shifter and the clock for data reception on all the time (the DCO reauires 6µs for wakeup, so even if activated as soon as a start bit is detected, it takes 2/3 of a startbit on 115kBd to get it running - the first byte is probably never received properly then) it might be a good idea to manually activate the download mode and onyl power the interface when required and keep the MSP awake (LPM0 at max) and the DCO stabilized until downlaod is complete.
    Maybe a mechanical switch on the connector or so that triggers a port interrupt.

    Now you're right, for I2C (or SPI, which I prefer for higher speed = shorter on times) teh exact frequency doesn't matter. And once the FLL has settled, the DCO will not drift too far from the optimum if you disable the FLL.

    However, before establishing a serial connection, you should run the FLL and let it stabilize the DCO again.

    The problem with low clock and serial connections is that for 9600Bd and a 32768Hz crystal, the divider is 3.41. So one bit is 3.41 clock cycles. Now the processor cannot know when 0.41 clock cycles might have passed. You can only use full integer dividers. So even with alternating between /3 and /4 (the modulation), the bit lengths are far from what the should be. Using a higher clock allows a larger and therefore more precise divider.

    For the RTC, the RTC module has an internal 16 bit divider, where bit 15 is taken for the 1s count in calendar mode. The counters are accessible directly (RTCPS register). However, since the RTC is clocked asynchroneously to the CPU, special care needs to be taken when reading htese registers, as the internal bits mach change during the read, giving a wrong result.

  • Jens-Michael, 

    Thank you for your very complete answer and sorry if i was a bit cofusing with my text.

    Thank you for your explanation about the FRAM devices and about how FLL will work on wake-up.

    The duty cycle i was refering is about the ratio between total time and time that MSP430 will be out of low-power mode (run mode). 

    Actually the reason i chose the MSP430F55/53 was just due to the price and nothing more. But anyway there is a small chance that we might change the communication to USB instead of serial but we are discussing that.

    The serial connetor will power the MSP430 so i am considering tracking that external supply with a pin so i can stop going into low power mode and keep FLL on. The device will have several seconds before the communication starts after that plug connection. 

    So just to make sure. Let supose i am clocking the MSP430 with 8MHz clock generated with DCO+FLL referenced on external 32KHz crystal. Is the baudrate i am going to get  stable enough for a 115200 bps communication? My doubt is due to the fact that the MSP 8Mhz frequency will be probably swicthing between two different frequencies correct?

    Second, how MSP430 behaves when changin power supply level? The reason i am asking that is because we are planning to use a TPS61221 in order to get a stable voltage from the batery when reading sensors.

    So basically when the MSP430 is in LPM it will turn-off  the TPS61221 and unpower the remaining circuit (sensors + FLASH) with a FET. When comes the time to sample the data and save into the flash it will turn TPS61221 on, power the circuit, wait a bit for all the sensos+SPI flash to settle, sample data, send to flash, and turn eveything down again.

    As i will have to mux the power between battery and external power, i will have a schottky diode + PNP Fet voltage drop. So basically the MSP430 power will be switching between something close to 2.9V (3.3V - aprox 0.4V) and 2.6V (battery - aprox 0.4V). Any problem on that? The DCO frequency will probably change, but thats not a problem as there will be no seral communication during that time.

    Thank you for all the help!

  • Luis Filipe Rossi said:
    So just to make sure. Let supose i am clocking the MSP430 with 8MHz clock generated with DCO+FLL referenced on external 32KHz crystal. Is the baudrate i am going to get  stable enough for a 115200 bps communication? My doubt is due to the fact that the MSP 8Mhz frequency will be probably swicthing between two different frequencies correct?

    That's correct. However, for a baudrate of 115200, you'll have a divider of ~70. The modulation pattern that switches between two frequencies (provided the FLL has settled and does not change the DCO), repeats every 32 clock cycles. So with a divider of >32 the jitter base don this is smoothed out almost entirely. And the FLL only changes between two modulation patterns, so the frequency change introduced by the FLL adjustment is small: 1/32 of a DCo frequency step (which is 2-12%). So the worst case jitter you'll see is 12/32=0.3%. It adds to the MAX errors given as listed in the baudrate table in the users guide. Still on the safe side. The precision of your FLL reference is more critical (the REFO has only 1.5%)
    I got a reliably working 115200Bd connection using REFO and 16MHz clock, which doesn't make too much difference (as good as 57600 on 8MHz)

    For the voltage change, well, there is a problem with fast rising transients on VCC. They may cause the BOR circuit trigger a reset when the voltage rises too fast (in V/s). THis is a known erratum caused by a racing condition in the BOR comparator. So you'll have to limit the speed in which the voltage rises by using a series resistor (maybe the muxer itself is enough) and a capacitor (larger than the minimum 4.7µ on VCC).

    For the core voltage, the Vcore capacitor keeps the CPU supply stable, so as long as VCC is above the required minimum voltage for the chose PMMCOREV (and CPU speed), the voltage change is not a problem. Only the transient at the moment of switching.

  • Thank you very much. I think that covers all my doubts about that specific device. I have a few questions about low power best practices but i will create a new topic for that. 

    Thank you for all the help!

**Attention** This is a public forum