Hi,

i finally found the reason for the brownouts: When the MSP430F149 sends a block
with more than 400 bytes via spi the IC often hangs in a state between working
and not working, when the supply voltage changes a few percent. 
I reduced the program to this bug example:

// This program shows the spi bug at the MSP430F149.
// The bug is visible with the two LEDs which can only be in the states 0x02 or
0x01
// if the program works correct, but in 90 % of the cases they are 0x00!
//
// Caution: After flashing this program the MSP430 refuses flashing until the
supply voltage
// is switched off for minutes! The BSL program reports communication error and
C-Spy reports
// could not read target memory!!!
//
//  Built with IAR Embedded Workbench Version: 1.26A
//

#include  <msp430x14x.h>

void
main (void)
{
  unsigned long int i = 0;

  WDTCTL = WDTPW + WDTHOLD;     // Stop WDT

  for (;;)                      // forever
  {
    P4DIR |= 0x03;              // Set P4 to output direction
    if (P4OUT &= 0x01)          // If LED1 is on
      P4OUT = 0x02;             // LED1 off, LED2 on
    else
      P4OUT = 0x01;             // LED1 on, LED2 off

    // initSPI:
    ME2 |= USPIE1;              // Enable USART1 SPI mode
    UTCTL1 = CKPH | SSEL1 | SSEL0 | STC;        // SMCLK, 3-pin mode, clock idle
low, data valid on rising edge, UCLK delayed
    UBR01 = 0x02;               // 0x02: UCLK/2
    UBR11 = 0x00;               // -"-
    UMCTL1 = 0x00;              // no modulation
    UCTL1 = CHAR | SYNC | MM;   // 8-bit SPI Master **SWRST**
    P5SEL |= 0x0E;              // P5.1-3 SPI option select
    P5DIR |= 0x01;              // P5.0 output direction
    P5OUT = 0xff;
    while (!(IFG2 & UTXIFG1));  // USART1 TX buffer ready (empty)?

    for (i = 0; i < 0xfffff; i++)   // With < 400 (instead of <
0xfffff) the bug is gone!
    {
      while (!(IFG2 & UTXIFG1));        // USART1 TX buffer ready (empty)?
      TXBUF1 = 0xff;            // send some bytes via spi
      while (!(IFG2 & UTXIFG1));        // USART1 TX buffer ready (empty)?
    }
  }  
}    

I wrote to TI but got no response.
Now i am using the workaround < 400 (instead of < 0xfffff) but i am not
sure if this works min. 2 years. If not my company would be in big trouble.
Does someone knows a better workaround?

The project file can be downloaded here (ziped together with the source code):

http://random.linux-site.net/files/unsorted/spi-bugs/spi_bug1.zip

Regards

Rolf F.

My question is where does it hang? Does it send the 400 bytes then hang, 
or does it hang at the same place every time, or is it arbitrary. I 
buffer a page at a time to the SPI serial dataflash, that's 528 bytes, 
and then stream it out, without problems, although, as I've said before, 
I usually use a decent regulator of some kind.

Al

nobodyo@nobo... wrote:
> Hi,
> 
> i finally found the reason for the brownouts: When the MSP430F149 sends a
block with more than 400 bytes via spi the IC often hangs in a state between
working and not working, when the supply voltage changes a few percent. 
> I reduced the program to this bug example:
> 
> // This program shows the spi bug at the MSP430F149.
> // The bug is visible with the two LEDs which can only be in the states
0x02 or 0x01
> // if the program works correct, but in 90 % of the cases they are 0x00!
> //
> // Caution: After flashing this program the MSP430 refuses flashing until
the supply voltage
> // is switched off for minutes! The BSL program reports communication error
and C-Spy reports
> // could not read target memory!!!
> //
> //  Built with IAR Embedded Workbench Version: 1.26A
> //
> 
> #include  <msp430x14x.h>
> 
> void
> main (void)
> {
>   unsigned long int i = 0;
> 
>   WDTCTL = WDTPW + WDTHOLD;     // Stop WDT
> 
>   for (;;)                      // forever
>   {
>     P4DIR |= 0x03;              // Set P4 to output direction
>     if (P4OUT &= 0x01)          // If LED1 is on
>       P4OUT = 0x02;             // LED1 off, LED2 on
>     else
>       P4OUT = 0x01;             // LED1 on, LED2 off
> 
>     // initSPI:
>     ME2 |= USPIE1;              // Enable USART1 SPI mode
>     UTCTL1 = CKPH | SSEL1 | SSEL0 | STC;        // SMCLK, 3-pin mode, clock
idle low, data valid on rising edge, UCLK delayed
>     UBR01 = 0x02;               // 0x02: UCLK/2
>     UBR11 = 0x00;               // -"-
>     UMCTL1 = 0x00;              // no modulation
>     UCTL1 = CHAR | SYNC | MM;   // 8-bit SPI Master **SWRST**
>     P5SEL |= 0x0E;              // P5.1-3 SPI option select
>     P5DIR |= 0x01;              // P5.0 output direction
>     P5OUT = 0xff;
>     while (!(IFG2 & UTXIFG1));  // USART1 TX buffer ready (empty)?
> 
>     for (i = 0; i < 0xfffff; i++)   // With < 400 (instead of
< 0xfffff) the bug is gone!
>     {
>       while (!(IFG2 & UTXIFG1));        // USART1 TX buffer ready
(empty)?
>       TXBUF1 = 0xff;            // send some bytes via spi
>       while (!(IFG2 & UTXIFG1));        // USART1 TX buffer ready
(empty)?
>     }
>   }  
> }    
> 
> I wrote to TI but got no response.
> Now i am using the workaround < 400 (instead of < 0xfffff) but i am
not sure if this works min. 2 years. If not my company would be in big trouble.
> Does someone knows a better workaround?
> 
> The project file can be downloaded here (ziped together with the source
code):
> 
> http://random.linux-site.net/files/unsorted/spi-bugs/spi_bug1.zip
> 
> Regards
> 
> Rolf F.
> 
> 
> 
> 
> .
> 
>  
> 
> ">http://docs.yahoo.com/info/terms/ 
> 
> 
> 

Hi Rolf,
A comment about your code (very likely that it will
cause the problem you are seeing but worth a try).
If P4.0 and P4.1 are output (and rest of the P4.x are
input) use logical ORing to set a port pin:
P4OUT |= 0x20;
and 
P4OUT &= ~0x20;
to reset the same port pin.
If you write to a port pin which is an input it will
cause increase in current consumption (and may be
voltage spikes)
Same applies for P5.
I'll try this code out with the TI board and see if I
can reproduce the problem.
-Sumukh

--- nobodyo@nobo... wrote:
> Hi,
> 
> i finally found the reason for the brownouts: When
> the MSP430F149 sends a block with more than 400
> bytes via spi the IC often hangs in a state between
> working and not working, when the supply voltage
> changes a few percent. 
> I reduced the program to this bug example:
> 
> // This program shows the spi bug at the MSP430F149.
> // The bug is visible with the two LEDs which can
> only be in the states 0x02 or 0x01
> // if the program works correct, but in 90 % of the
> cases they are 0x00!
> //
> // Caution: After flashing this program the MSP430
> refuses flashing until the supply voltage
> // is switched off for minutes! The BSL program
> reports communication error and C-Spy reports
> // could not read target memory!!!
> //
> //  Built with IAR Embedded Workbench Version: 1.26A
> //
> 
> #include  <msp430x14x.h>
> 
> void
> main (void)
> {
>   unsigned long int i = 0;
> 
>   WDTCTL = WDTPW + WDTHOLD;     // Stop WDT
> 
>   for (;;)                      // forever
>   {
>     P4DIR |= 0x03;              // Set P4 to output
> direction
>     if (P4OUT &= 0x01)          // If LED1 is on
>       P4OUT = 0x02;             // LED1 off, LED2 on
>     else
>       P4OUT = 0x01;             // LED1 on, LED2 off
> 
>     // initSPI:
>     ME2 |= USPIE1;              // Enable USART1 SPI
> mode
>     UTCTL1 = CKPH | SSEL1 | SSEL0 | STC;        //
> SMCLK, 3-pin mode, clock idle low, data valid on
> rising edge, UCLK delayed
>     UBR01 = 0x02;               // 0x02: UCLK/2
>     UBR11 = 0x00;               // -"-
>     UMCTL1 = 0x00;              // no modulation
>     UCTL1 = CHAR | SYNC | MM;   // 8-bit SPI Master
> **SWRST**
>     P5SEL |= 0x0E;              // P5.1-3 SPI option
> select
>     P5DIR |= 0x01;              // P5.0 output
> direction
>     P5OUT = 0xff;
>     while (!(IFG2 & UTXIFG1));  // USART1 TX buffer
> ready (empty)?
> 
>     for (i = 0; i < 0xfffff; i++)   // With < 400
> (instead of < 0xfffff) the bug is gone!
>     {
>       while (!(IFG2 & UTXIFG1));        // USART1 TX
> buffer ready (empty)?
>       TXBUF1 = 0xff;            // send some bytes
> via spi
>       while (!(IFG2 & UTXIFG1));        // USART1 TX
> buffer ready (empty)?
>     }
>   }  
> }    
> 
> I wrote to TI but got no response.
> Now i am using the workaround < 400 (instead of <
> 0xfffff) but i am not sure if this works min. 2
> years. If not my company would be in big trouble.
> Does someone knows a better workaround?
> 
> The project file can be downloaded here (ziped
> together with the source code):
> 
>
http://random.linux-site.net/files/unsorted/spi-bugs/spi_bug1.zip
> 
> Regards
> 
> Rolf F.
> 
> 
> 


__________________________________

Sumukh:

To clarify, you're not saying that setting a bit in the port output
register will cause high current consumption, when the corresponding bit is
reset in the port's input register, are you?  Maybe you're saying that
if
one inadvertantly sets an externally driven pin to output, then writes in
opposition to the external level, lots of current flows.  But the state of
the output bit wouldn't matter if it's not connected to the pin.

But that's definitely a good guess for brownout problems, though seems the
supply'd have to be pretty high impedance for these wimpy ports to affect
supply voltage to such a degree...

--Bruce

> Hi Rolf,
> A comment about your code (very likely that it will
> cause the problem you are seeing but worth a try).
> If P4.0 and P4.1 are output (and rest of the P4.x are
> input) use logical ORing to set a port pin:
> P4OUT |= 0x20;
> and
> P4OUT &= ~0x20;
> to reset the same port pin.
> If you write to a port pin which is an input it will
> cause increase in current consumption (and may be
> voltage spikes)
> Same applies for P5.
> I'll try this code out with the TI board and see if I
> can reproduce the problem.
> -Sumukh

Hi,

i reduced the program with the bug to the following hello world program and  the
bug is still inside:

void
main (void)
{
  volatile unsigned long int i = 0;

  WDTCTL = WDTPW + WDTHOLD;     // Stop WDT

  _DINT ();                     // Block Interrupts

  for (;;)                      // forever
  {
    P4DIR = 0x03;               // LED-Pins
    P4SEL = 0x00;               // no special function
    P4OUT = 0x03;               // LEDs on
    for (i = 0; i < 32000; i++);
    P4OUT = 0x00;               // LEDs off
    for (i = 0; i < 32000; i++);
  }
}

This Hello World Program shows min. one Bug because even with a stable supply
voltage:
 a) None of the LEDs blinks.
 b) In nearly every case none of the LEDs is on and if not than only the red one
(0x01) is on
    (the Debuger C-Spy shows 0xa1 in P4OUT ).
 c) The IC can't be flashed without shorting the supply voltage for
minutes.

I don't know why this doesn't work. With the full program (>30 k
Code) the MSP430 works stable when the supply voltage is stable and he
communicates with a MMC/SD Card and over RS232 without errors and the real time
clock works without problems. Even the program output over the LEDs is correct.

I've put the source code together with the project file (IAR 1.26A) here:
http://random.linux-site.net/files/unsorted/spi-bugs/bug3.zip

Regards

Rolf F.

Hi Rolf,
I tried your program (the one which appears below) and
it worked fine. I could not use the projet file that
you have on the website as I do not have the same .xcl
file.
I got the following error:
Error[e12]: Unable to open file
'E:\iar\embedded_workbench\430\icc430\lnk430m.xcl' 

I used the TI project which blinks an LED, removed the
.c file and put the one that you have on the website
and compiled it. Hooked up oscilloscope probes to P4.0
and P4.1 and it showed a nice square wave.
There is probably something wrong with your project
settings.
I used the TI test.prj file in the following location:
<Install directory>\430\FET_examples\FET140\C

-Sumukh

--- nobodyo@nobo... wrote:
> Hi,
> 
> i reduced the program with the bug to the following
> hello world program and  the bug is still inside:
> 
> void
> main (void)
> {
>   volatile unsigned long int i = 0;
> 
>   WDTCTL = WDTPW + WDTHOLD;     // Stop WDT
> 
>   _DINT ();                     // Block Interrupts
> 
>   for (;;)                      // forever
>   {
>     P4DIR = 0x03;               // LED-Pins
>     P4SEL = 0x00;               // no special
> function
>     P4OUT = 0x03;               // LEDs on
>     for (i = 0; i < 32000; i++);
>     P4OUT = 0x00;               // LEDs off
>     for (i = 0; i < 32000; i++);
>   }
> }
> 
> This Hello World Program shows min. one Bug because
> even with a stable supply voltage:
>  a) None of the LEDs blinks.
>  b) In nearly every case none of the LEDs is on and
> if not than only the red one (0x01) is on
>     (the Debuger C-Spy shows 0xa1 in P4OUT ).
>  c) The IC can't be flashed without shorting the
> supply voltage for minutes.
> 
> I don't know why this doesn't work. With the full
> program (>30 k Code) the MSP430 works stable when
> the supply voltage is stable and he communicates
> with a MMC/SD Card and over RS232 without errors and
> the real time clock works without problems. Even the
> program output over the LEDs is correct.
> 
> I've put the source code together with the project
> file (IAR 1.26A) here:
>
http://random.linux-site.net/files/unsorted/spi-bugs/bug3.zip
> 
> Regards
> 
> Rolf F.
> 
> 
> 


__________________________________

If he can't run a blinky-LED program reliably, and can't recover
the
crashed system even after five minutes of shorting the power supply, I've
got fifty bucks that says the problem is with his custom hardware.

Even if he showed us the schematic, it's more than likely it'll turn
out to
be a solder bridge or other OOPS, just like people write about here so
often after we spend a few days brainstorming software solutions.  ;)

--Bruce


> Hi Rolf,
> I tried your program (the one which appears below) and
> it worked fine. I could not use the projet file that
> you have on the website as I do not have the same .xcl
> file.
> I got the following error:
> Error[e12]: Unable to open file
> 'E:\iar\embedded_workbench\430\icc430\lnk430m.xcl'
>
> I used the TI project which blinks an LED, removed the
> .c file and put the one that you have on the website
> and compiled it. Hooked up oscilloscope probes to P4.0
> and P4.1 and it showed a nice square wave.
> There is probably something wrong with your project
> settings.
> I used the TI test.prj file in the following location:
> <Install directory>\430\FET_examples\FET140\C
>
> -Sumukh
>
> --- nobodyo@nobo... wrote:
> > Hi,
> >
> > i reduced the program with the bug to the following
> > hello world program and  the bug is still inside:
> >
> > void
> > main (void)
> > {
> >   volatile unsigned long int i = 0;
> >
> >   WDTCTL = WDTPW + WDTHOLD;     // Stop WDT
> >
> >   _DINT ();                     // Block Interrupts
> >
> >   for (;;)                      // forever
> >   {
> >     P4DIR = 0x03;               // LED-Pins
> >     P4SEL = 0x00;               // no special
> > function
> >     P4OUT = 0x03;               // LEDs on
> >     for (i = 0; i < 32000; i++);
> >     P4OUT = 0x00;               // LEDs off
> >     for (i = 0; i < 32000; i++);
> >   }
> > }
> >
> > This Hello World Program shows min. one Bug because
> > even with a stable supply voltage:
> >  a) None of the LEDs blinks.
> >  b) In nearly every case none of the LEDs is on and
> > if not than only the red one (0x01) is on
> >     (the Debuger C-Spy shows 0xa1 in P4OUT ).
> >  c) The IC can4t be flashed without shorting the
> > supply voltage for minutes.
> >
> > I don4t know why this doesn4t work. With the full
> > program (>30 k Code) the MSP430 works stable when
> > the supply voltage is stable and he communicates
> > with a MMC/SD Card and over RS232 without errors and
> > the real time clock works without problems. Even the
> > program output over the LEDs is correct.
> >
> > I4ve put the source code together with the project
> > file (IAR 1.26A) here:
> >
> http://random.linux-site.net/files/unsorted/spi-bugs/bug3.zip
> >
> > Regards
> >
> > Rolf F.
> >
> >
> >
>
>
> __________________________________
> 
>
>
> .
>
>
>
> ">http://docs.yahoo.com/info/terms/

Hi,

> I tried your program (the one which appears below)
and
> it worked fine. I could not use the projet file that
> you have on the website as I do not have the same .xcl

You're right. The hello world programs, and only these, used the default
lnk430m.xcl and that produce trash that could be flashed and run without even a
warning! With the right one (msp430F149C.xcl) the hello world programs are
working.

I finally found the reason for the brownouts: If the voltage drops to or below
2,7 V for some ms then the MSP430 hangs. If the voltage drops to or below 2.6 V
for some ms this often produces hard brownouts where the reset does not help and
sometimes new flashing can't be done without shorting the supply voltage
for minutes. I could fix the hangups and brownouts with a large 1 F gold cap.
Now i'm using a ISR to switch to LPM3 so fast that the voltage is always
below 2,7 V. The big gold cap is not nessesary with this ISR.
The reason why the MSP430 hangs with high deadlines for SPI-communication is
than the waiting delays the check and change to LPM3 and this delay drops the
supply voltage at the MSP430. The SPI-communication seems to be stable if the
uart is software-resetet before setting the uart registers.

Regards

Rolf F.

Glad to know that it fixed the problem. 
-Sumukh

--- nobodyo@nobo... wrote:
> Hi,
> 
> > I tried your program (the one which appears below)
> and
> > it worked fine. I could not use the projet file
> that
> > you have on the website as I do not have the same
> .xcl
> 
> You're right. The hello world programs, and only
> these, used the default lnk430m.xcl and that produce
> trash that could be flashed and run without even a
> warning! With the right one (msp430F149C.xcl) the
> hello world programs are working.
> 
> I finally found the reason for the brownouts: If the
> voltage drops to or below 2,7 V for some ms then the
> MSP430 hangs. If the voltage drops to or below 2.6 V
> for some ms this often produces hard brownouts where
> the reset does not help and sometimes new flashing
> can't be done without shorting the supply voltage
> for minutes. I could fix the hangups and brownouts
> with a large 1 F gold cap. Now i'm using a ISR to
> switch to LPM3 so fast that the voltage is always
> below 2,7 V. The big gold cap is not nessesary with
> this ISR.
> The reason why the MSP430 hangs with high deadlines
> for SPI-communication is than the waiting delays the
> check and change to LPM3 and this delay drops the
> supply voltage at the MSP430. The SPI-communication
> seems to be stable if the uart is software-resetet
> before setting the uart registers.
> 
> Regards
> 
> Rolf F.
> 
> 
> 


__________________________________

nobodyo@nobo... wrote:
> Hi,
> 
> 
>> I tried your program (the one which appears below) and it worked
>> fine. I could not use the projet file that you have on the website
>> as I do not have the same .xcl
> 
> 
> You're right. The hello world programs, and only these, used the
> default lnk430m.xcl and that produce trash that could be flashed and
> run without even a warning! With the right one (msp430F149C.xcl) the
> hello world programs are working.
> 
> I finally found the reason for the brownouts: If the voltage drops to
> or below 2,7 V for some ms then the MSP430 hangs. If the voltage
> drops to or below 2.6 V for some ms this often produces hard
> brownouts where the reset does not help and sometimes new flashing
> can't be done without shorting the supply voltage for minutes.

??????

I have run MSP430's with SCI/SPI at voltages down to and even slightly 
below 1.8V, with no problems. I've run down to 2.4V at 16MHz in a 
freezer, and in an oven at the same temperatures, implicitly looking, 
and logging any clock glitches/resets/flash isssues etc. never a one 
across many boards, in nearly 3 years. My standard storage device is an 
SPI Atmel AT45BD161, with a 528 byte page. I have tested this with 
continuously powered systems, ie no low power modes, and with low power 
modes. I've NEVER seen anything like you are experiencing. I don't use

big caps to hold up the supply


> I
> could fix the hangups and brownouts with a large 1 F gold cap. Now
> i'm using a ISR to switch to LPM3 so fast that the voltage is always
> below 2,7 V. The big gold cap is not nessesary with this ISR. The
> reason why the MSP430 hangs with high deadlines for SPI-communication
> is than the waiting delays the check and change to LPM3 and this
> delay drops the supply voltage at the MSP430. The SPI-communication
> seems to be stable if the uart is software-resetet before setting the
> uart registers.

None of this makes any sense what so ever. Why is your supply drooping 
so badly if left powered? What is your power source? In a previous post 
you stated that this happened when running on a PSU or on batteries! 
Again it makes no sense that a PSU would be so overloaded by an MSP that 
it would droop that way. Even batteries shouldn't do that, even slightly 
worn coin cells of adequate continuous current rating don't do that. I 
know. I've hammered all sorts of battery technologies logging their 
characteristics under all sorts of operating conditions.

Why would the SPI in particular load down the PSU if left on. The MSP 
end of the SPI draws very little additional current? Although perhaps 
the implication is that something else is loading the supply because of 
the longer interval required to service the SPI. You must always reset 
the UARTs before using them, but not every time, only when first 
initialised. That is clearly spelled out in the data sheets. Even my 
systems that don't use the UARTs rest them in the INIT procedures. What 
sort of current is your system drawing? I have systems running on L-Poly 
cells that draw up to 400mA, and one running on a PSU that draws over 
10A, still I can't repeat your problems. To me that suggests you still 
have hardware issues, since you are experiencing this problem well 
within the rated operation of the MSP, and, I figure that if it was a 
generic issue at least one or more of us would have experienced it 
before now.

Please don't take this as negative. It is in your own interests to 
absolutely identify this issue before shipping any product, and I'm 
convinced you haven't yet.

Al