I'm reading in the MSP430F2272 datasheet on page 30 about the POR/BOR
behavior.
How should I interpret the "test conditions" column in the table at the
top of the page? It says "dVcc/dt <= 3V/s".
Where can I find something that tells me what the min and max voltage
rise rates need to be for safe operation?
I know this has been discussed various times on the group, but none of
the previous posts (that I could find at least) seemed to state what the
rise times should be.
My current problem is that the voltage rises up to about 1.3V and dwells
there for 5 to 10ms before rising the rest of the way to 3.3V. When
that happens, the MCU will never operate correctly, despite being reset
manually. I'm assuming that the hardware goes into a weird state that
cannot be recovered from. Any advice or comments would be greatly
appreciated.
Thanks,
Aaron
MSP430F2272 - POR/BOR - How to interpret the datasheet?
Started by ●July 15, 2009
Reply by ●July 16, 20092009-07-16
I wonder if you are willing to perform the following experiment.
Manually hold the nRST pin to ground before you start the power up until the voltage reaches 1.71V (or above). At that point, you release the nRST pin. Does the MCU ever get stuck this way?
I know this is not a solution for your problem, but it might shed some light on the origin of your problem. My suspicion is that the brownout circuit is not doing what Fig. 9 says.
--- In m..., Aaron Greer wrote:
>
> I'm reading in the MSP430F2272 datasheet on page 30 about the POR/BOR
> behavior.
> How should I interpret the "test conditions" column in the table at the
> top of the page? It says "dVcc/dt <= 3V/s".
> Where can I find something that tells me what the min and max voltage
> rise rates need to be for safe operation?
> I know this has been discussed various times on the group, but none of
> the previous posts (that I could find at least) seemed to state what the
> rise times should be.
> My current problem is that the voltage rises up to about 1.3V and dwells
> there for 5 to 10ms before rising the rest of the way to 3.3V. When
> that happens, the MCU will never operate correctly, despite being reset
> manually. I'm assuming that the hardware goes into a weird state that
> cannot be recovered from. Any advice or comments would be greatly
> appreciated.
> Thanks,
> Aaron
>
Manually hold the nRST pin to ground before you start the power up until the voltage reaches 1.71V (or above). At that point, you release the nRST pin. Does the MCU ever get stuck this way?
I know this is not a solution for your problem, but it might shed some light on the origin of your problem. My suspicion is that the brownout circuit is not doing what Fig. 9 says.
--- In m..., Aaron Greer wrote:
>
> I'm reading in the MSP430F2272 datasheet on page 30 about the POR/BOR
> behavior.
> How should I interpret the "test conditions" column in the table at the
> top of the page? It says "dVcc/dt <= 3V/s".
> Where can I find something that tells me what the min and max voltage
> rise rates need to be for safe operation?
> I know this has been discussed various times on the group, but none of
> the previous posts (that I could find at least) seemed to state what the
> rise times should be.
> My current problem is that the voltage rises up to about 1.3V and dwells
> there for 5 to 10ms before rising the rest of the way to 3.3V. When
> that happens, the MCU will never operate correctly, despite being reset
> manually. I'm assuming that the hardware goes into a weird state that
> cannot be recovered from. Any advice or comments would be greatly
> appreciated.
> Thanks,
> Aaron
>
Reply by ●July 16, 20092009-07-16
--- In m..., Aaron Greer wrote:
> ... My current problem is that the voltage rises up to about
> 1.3V and dwells there for 5 to 10ms before rising the rest
> of the way to 3.3V ...
Aaron,
I wonder if that hesitation is the cause or the consequence of MCU being stuck. Is there any chance that you can observe the current consumption during power up?
-- OCY
> ... My current problem is that the voltage rises up to about
> 1.3V and dwells there for 5 to 10ms before rising the rest
> of the way to 3.3V ...
Aaron,
I wonder if that hesitation is the cause or the consequence of MCU being stuck. Is there any chance that you can observe the current consumption during power up?
-- OCY
Reply by ●July 20, 20092009-07-20
> > How should I interpret the "test conditions" column
in the table > > at the top of the page? It says "dVcc/dt <= 3V/s".
Actually, IMO this parameter should be >= and not <=, others have commented so as well. Some have pointed out previously that if Vcc raises too slowly, the MSP430 will never start operating, no matter what you do with the Reset pin.
You could use a voltage regulator like the TPS770xx family which has as low as 50mV drop-out at 50mA and a very 17uA oprating quiescent current (from your power source description I guess this parameters are important in your design) and it has an enable pin you can use so it starts up when the input voltage reaches a certain minimum. That way the MSP Vcc rail raises much faster, within the specified minimum.
Or you could use a TPS3803 Voltage Detector to control a power switch to the MSP430 Vcc pin.
The bad thing is, the voltage regulation circuit may end up costing more than the MSP430 itself.
I guess there are voltage regulators with supervisory circuit that may be cheaper than the TPS3803+770xx solution, but when I had this problem I didn't find one in the limited time I had to look for (and import) a chip. Luckyly cost wasn't an issue this time.
Regards,
Michael K.
--- In m..., "old_cow_yellow" wrote:
>
> I wonder if you are willing to perform the following experiment.
>
> Manually hold the nRST pin to ground before you start the power up until the voltage reaches 1.71V (or above). At that point, you release the nRST pin. Does the MCU ever get stuck this way?
>
> I know this is not a solution for your problem, but it might shed some light on the origin of your problem. My suspicion is that the brownout circuit is not doing what Fig. 9 says.
>
> --- In m..., Aaron Greer wrote:
> >
> > I'm reading in the MSP430F2272 datasheet on page 30 about the POR/BOR
> > behavior.
> > How should I interpret the "test conditions" column in the table at the
> > top of the page? It says "dVcc/dt <= 3V/s".
> > Where can I find something that tells me what the min and max voltage
> > rise rates need to be for safe operation?
> > I know this has been discussed various times on the group, but none of
> > the previous posts (that I could find at least) seemed to state what the
> > rise times should be.
> > My current problem is that the voltage rises up to about 1.3V and dwells
> > there for 5 to 10ms before rising the rest of the way to 3.3V. When
> > that happens, the MCU will never operate correctly, despite being reset
> > manually. I'm assuming that the hardware goes into a weird state that
> > cannot be recovered from. Any advice or comments would be greatly
> > appreciated.
> > Thanks,
> > Aaron
>
Actually, IMO this parameter should be >= and not <=, others have commented so as well. Some have pointed out previously that if Vcc raises too slowly, the MSP430 will never start operating, no matter what you do with the Reset pin.
You could use a voltage regulator like the TPS770xx family which has as low as 50mV drop-out at 50mA and a very 17uA oprating quiescent current (from your power source description I guess this parameters are important in your design) and it has an enable pin you can use so it starts up when the input voltage reaches a certain minimum. That way the MSP Vcc rail raises much faster, within the specified minimum.
Or you could use a TPS3803 Voltage Detector to control a power switch to the MSP430 Vcc pin.
The bad thing is, the voltage regulation circuit may end up costing more than the MSP430 itself.
I guess there are voltage regulators with supervisory circuit that may be cheaper than the TPS3803+770xx solution, but when I had this problem I didn't find one in the limited time I had to look for (and import) a chip. Luckyly cost wasn't an issue this time.
Regards,
Michael K.
--- In m..., "old_cow_yellow" wrote:
>
> I wonder if you are willing to perform the following experiment.
>
> Manually hold the nRST pin to ground before you start the power up until the voltage reaches 1.71V (or above). At that point, you release the nRST pin. Does the MCU ever get stuck this way?
>
> I know this is not a solution for your problem, but it might shed some light on the origin of your problem. My suspicion is that the brownout circuit is not doing what Fig. 9 says.
>
> --- In m..., Aaron Greer wrote:
> >
> > I'm reading in the MSP430F2272 datasheet on page 30 about the POR/BOR
> > behavior.
> > How should I interpret the "test conditions" column in the table at the
> > top of the page? It says "dVcc/dt <= 3V/s".
> > Where can I find something that tells me what the min and max voltage
> > rise rates need to be for safe operation?
> > I know this has been discussed various times on the group, but none of
> > the previous posts (that I could find at least) seemed to state what the
> > rise times should be.
> > My current problem is that the voltage rises up to about 1.3V and dwells
> > there for 5 to 10ms before rising the rest of the way to 3.3V. When
> > that happens, the MCU will never operate correctly, despite being reset
> > manually. I'm assuming that the hardware goes into a weird state that
> > cannot be recovered from. Any advice or comments would be greatly
> > appreciated.
> > Thanks,
> > Aaron
>
Reply by ●July 31, 20092009-07-31
I did some primitive experiments to verify the POR/BOR specification in the
data-sheet. Specifically, I tested a MSP430F2471 with respect to the
characteristics table and graph on page 39 of the data-sheet slas547c.pdf.
First of all, I think the stated "TEST CONDITIONS" on the data-sheet is correct. I tried to ramp Vcc up and down at dVcc/dt = 3V/s, 0.06V/s, and 0.0006V/s; they all show the same results consistent with what the table specifies. For the chip I tested, in all cases the CPU starts to run at 1.53V (during ramp up) and stops to run (during ramp down) at 1.40V.
Also, in my tests, the CPU never crashes or stalls no matter how slow Vcc ramps up. (However, if the firmware increases the clock rate while Vcc is not sufficient for that clock rate, of course it might crash.)
--- In m..., "tintronic" wrote:
>
> > > How should I interpret the "test conditions" column in the table > > at the top of the page? It says "dVcc/dt <= 3V/s".
> Actually, IMO this parameter should be >= and not <=, others have commented so as well. Some have pointed out previously that if Vcc raises too slowly, the MSP430 will never start operating, no matter what you do with the Reset pin.
> You could use a voltage regulator like the TPS770xx family which has as low as 50mV drop-out at 50mA and a very 17uA oprating quiescent current (from your power source description I guess this parameters are important in your design) and it has an enable pin you can use so it starts up when the input voltage reaches a certain minimum. That way the MSP Vcc rail raises much faster, within the specified minimum.
> Or you could use a TPS3803 Voltage Detector to control a power switch to the MSP430 Vcc pin.
> The bad thing is, the voltage regulation circuit may end up costing more than the MSP430 itself.
> I guess there are voltage regulators with supervisory circuit that may be cheaper than the TPS3803+770xx solution, but when I had this problem I didn't find one in the limited time I had to look for (and import) a chip. Luckyly cost wasn't an issue this time.
>
> Regards,
> Michael K.
> --- In m..., "old_cow_yellow" wrote:
> >
> > I wonder if you are willing to perform the following experiment.
> >
> > Manually hold the nRST pin to ground before you start the power up until the voltage reaches 1.71V (or above). At that point, you release the nRST pin. Does the MCU ever get stuck this way?
> >
> > I know this is not a solution for your problem, but it might shed some light on the origin of your problem. My suspicion is that the brownout circuit is not doing what Fig. 9 says.
> >
> > --- In m..., Aaron Greer wrote:
> > >
> > > I'm reading in the MSP430F2272 datasheet on page 30 about the POR/BOR
> > > behavior.
> > > How should I interpret the "test conditions" column in the table at the
> > > top of the page? It says "dVcc/dt <= 3V/s".
> > > Where can I find something that tells me what the min and max voltage
> > > rise rates need to be for safe operation?
> > > I know this has been discussed various times on the group, but none of
> > > the previous posts (that I could find at least) seemed to state what the
> > > rise times should be.
> > > My current problem is that the voltage rises up to about 1.3V and dwells
> > > there for 5 to 10ms before rising the rest of the way to 3.3V. When
> > > that happens, the MCU will never operate correctly, despite being reset
> > > manually. I'm assuming that the hardware goes into a weird state that
> > > cannot be recovered from. Any advice or comments would be greatly
> > > appreciated.
> > > Thanks,
> > > Aaron
> > >
>
First of all, I think the stated "TEST CONDITIONS" on the data-sheet is correct. I tried to ramp Vcc up and down at dVcc/dt = 3V/s, 0.06V/s, and 0.0006V/s; they all show the same results consistent with what the table specifies. For the chip I tested, in all cases the CPU starts to run at 1.53V (during ramp up) and stops to run (during ramp down) at 1.40V.
Also, in my tests, the CPU never crashes or stalls no matter how slow Vcc ramps up. (However, if the firmware increases the clock rate while Vcc is not sufficient for that clock rate, of course it might crash.)
--- In m..., "tintronic" wrote:
>
> > > How should I interpret the "test conditions" column in the table > > at the top of the page? It says "dVcc/dt <= 3V/s".
> Actually, IMO this parameter should be >= and not <=, others have commented so as well. Some have pointed out previously that if Vcc raises too slowly, the MSP430 will never start operating, no matter what you do with the Reset pin.
> You could use a voltage regulator like the TPS770xx family which has as low as 50mV drop-out at 50mA and a very 17uA oprating quiescent current (from your power source description I guess this parameters are important in your design) and it has an enable pin you can use so it starts up when the input voltage reaches a certain minimum. That way the MSP Vcc rail raises much faster, within the specified minimum.
> Or you could use a TPS3803 Voltage Detector to control a power switch to the MSP430 Vcc pin.
> The bad thing is, the voltage regulation circuit may end up costing more than the MSP430 itself.
> I guess there are voltage regulators with supervisory circuit that may be cheaper than the TPS3803+770xx solution, but when I had this problem I didn't find one in the limited time I had to look for (and import) a chip. Luckyly cost wasn't an issue this time.
>
> Regards,
> Michael K.
> --- In m..., "old_cow_yellow" wrote:
> >
> > I wonder if you are willing to perform the following experiment.
> >
> > Manually hold the nRST pin to ground before you start the power up until the voltage reaches 1.71V (or above). At that point, you release the nRST pin. Does the MCU ever get stuck this way?
> >
> > I know this is not a solution for your problem, but it might shed some light on the origin of your problem. My suspicion is that the brownout circuit is not doing what Fig. 9 says.
> >
> > --- In m..., Aaron Greer wrote:
> > >
> > > I'm reading in the MSP430F2272 datasheet on page 30 about the POR/BOR
> > > behavior.
> > > How should I interpret the "test conditions" column in the table at the
> > > top of the page? It says "dVcc/dt <= 3V/s".
> > > Where can I find something that tells me what the min and max voltage
> > > rise rates need to be for safe operation?
> > > I know this has been discussed various times on the group, but none of
> > > the previous posts (that I could find at least) seemed to state what the
> > > rise times should be.
> > > My current problem is that the voltage rises up to about 1.3V and dwells
> > > there for 5 to 10ms before rising the rest of the way to 3.3V. When
> > > that happens, the MCU will never operate correctly, despite being reset
> > > manually. I'm assuming that the hardware goes into a weird state that
> > > cannot be recovered from. Any advice or comments would be greatly
> > > appreciated.
> > > Thanks,
> > > Aaron
> > >
>
