That makes absolutely no sense at all. It needn't be  stack overflow,
it 
is more likely to be stack corruption. Unless there is a significant 
amountof overheating there is no reason why there should be a difference 
between 10 minutes power down, and 5 hours, unless you are encountering 
a similar issue to the POR problems of the '149 and other early parts. 
ie if time makes a difference something is draining away over time. If 
it is vcc you can measure it normally as low voltages, and if it is 
thermal you can measure that. There ius nothing else rational that would 
be present, but there is always the irrational I guess.You've tried 
changing micros, have you tried different memory cards, or brands of 
cards/ . Ignore whether or not they worked before. The fact that a reset 
does not help is irrelevant. A reset is NOT the same as powering on from 
a cold start. Have you trapped all possible interrupt vectors?

Al

rolf.freitag@rolf... wrote:

>Hi,
>
>  
>
>>Time related errors like 
>>this are nearly always software related since this is the only thing 
>>which alwasy does exactly the same thing exactly the same way each time 
>>it runs.
>>    
>>
>
>it's not uptime related because a reset does not help; it's supply
voltage time related.
>After 10 minutes power down it does not work but after 5 hours power down it
works
>(for one minute).
>
>And i'm using a stack checking function which shows that there is no
stack overflow.
>
>Regards,
>
>Rolf 
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>

On Sun, 31 Jul 2005 20:58:05 +0200, rolf.freitag@rolf... wrote:



>Hi,

>> Time related errors like 
>> this are nearly always software related since this is the only thing 
>> which alwasy does exactly the same thing exactly the same way each time

>> it runs.

>it's not uptime related because a reset does
not help; it's supply voltage time related.
>After 10 minutes power down it does not work but after 5 hours power down it
works
>(for one minute).

>And i'm using a stack checking function which
shows that there is no stack overflow.



How about after 5 hours you start the system up.  Then after say 30 secs of
runtime
you press RESET and see if the problem happens either 30 secs later or 1 min
later.
The former would tend to indicate a hardware problem while the latter would
indicate
a software issue.

Regards
-Bill Knight
R O SoftWare

It sound a bit like a hardware thermal problem. Takes a few minutes to warm
up, longer to cool off.

Try a can of freeze mist - see if you can bring it back. Maybe even isolate
the thermally sensitive component (or connection, like a cracked trace or
solder joint).


Al Somerville
Terran Scientific




-----Original Message-----
From: msp430@msp4... [mailto:msp430@msp4...] On Behalf Of
rolf.freitag@rolf...
Sent: Sunday, July 31, 2005 11:58 AM
To: msp430@msp4...
Subject: Re: [msp430] I2C EEPROM: Write works, Read not



Hi,

> Time related errors like 
> this are nearly always software related since this is the only thing 
> which alwasy does exactly the same thing exactly the same way each time 
> it runs.

it's not uptime related because a reset does not help; it's supply
voltage
time related.
After 10 minutes power down it does not work but after 5 hours power down it
works
(for one minute).

And i'm using a stack checking function which shows that there is no stack
overflow.

Regards,

Rolf 




.

 
Yahoo! Groups Links



 

But this isn't what he described, and I would still not discount the 
software since the problem could well be in the restting of the device. 
there is a diffeence between a POR and a reset.  As Rolf describes his 
problemit it sounds more like a software issue, since he has a small 
value resistor between Vcc and GND, which should solve the problem if it 
were related to POR and incorrectly opeating RESET. Although he has 
stated that RESET makes no difference, he hasn't said if the no 
dofference is that it carries on as it was, or resets but exhibits the 
same behaviour. He also hasn't said how he is determining the that write 
works and read doesn't since the only way to really determine this is 
with a scope to view the I/O lines, and he hasn't done this. assuming 
the read doesn't work because he doesn't get the expected result is
not 
good fault finding practice. My main reason for jumping in was because 
Rolf was jumping to conclusions without adequate evidence. the sort of 
thing we all experience. As  a hardware guy the programmers always blame 
your hardware, and as a programmer the hardware guys always blame the 
code. Without adequate and logical fault finding processes in place you 
cannot make the assumptions he was.

Al

Bill Knight wrote:

>On Sun, 31 Jul 2005 20:58:05 +0200,
rolf.freitag@rolf... wrote:
>
>
>
>  
>
>>Hi,
>>    
>>
>
>  
>
>>>Time related errors like 
>>>this are nearly always software related since this is the only thing

>>>which alwasy does exactly the same thing exactly the same way each
time 
>>>it runs.
>>>      
>>>
>
>  
>
>>it's not uptime related because a reset does not help; it's
supply voltage time related.
>>After 10 minutes power down it does not work but after 5 hours power
down it works
>>(for one minute).
>>    
>>
>
>  
>
>>And i'm using a stack checking function which shows that there is
no stack overflow.
>>    
>>
>
>
>
>How about after 5 hours you start the system up.  Then after say 30 secs of
runtime
>you press RESET and see if the problem happens either 30 secs later or 1 min
later.
>The former would tend to indicate a hardware problem while the latter would
indicate
>a software issue.
>
>Regards
>-Bill Knight
>R O SoftWare
>
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>  
>

5 hours? if it were that hot you should be able to feel it. Of course if 
he has only tried 10 minutes and 5 hours we have no way of knowing how 
long it takes to return, and if this is a constant value. His fault 
finding processes are knee jerk, not logical.

Al

Al Somerville wrote:

>It sound a bit like a hardware thermal problem.
Takes a few minutes to warm
>up, longer to cool off.
>
>Try a can of freeze mist - see if you can bring it back. Maybe even isolate
>the thermally sensitive component (or connection, like a cracked trace or
>solder joint).
>
>
>Al Somerville
>Terran Scientific
>
>
>
>
>-----Original Message-----
>From: msp430@msp4... [mailto:msp430@msp4...] On Behalf Of
>rolf.freitag@rolf...
>Sent: Sunday, July 31, 2005 11:58 AM
>To: msp430@msp4...
>Subject: Re: [msp430] I2C EEPROM: Write works, Read not
>
>
>
>Hi,
>
>  
>
>>Time related errors like 
>>this are nearly always software related since this is the only thing 
>>which alwasy does exactly the same thing exactly the same way each time 
>>it runs.
>>    
>>
>
>it's not uptime related because a reset does not help; it's supply
voltage
>time related.
>After 10 minutes power down it does not work but after 5 hours power down it
>works
>(for one minute).
>
>And i'm using a stack checking function which shows that there is no
stack
>overflow.
>
>Regards,
>
>Rolf 
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>

You are correct Al.  I haven't worked with the MSP in a while and
forgot
about the differences between RESET & POR.  Also about the RESET problem
some of the MSPs have exhibited in the past.

-Bill



On Mon, 01 Aug 2005 18:58:30 +0930, Onestone wrote:

>But this isn't what he described, and I would
still not discount the 
>software since the problem could well be in the restting of the device. 
>there is a diffeence between a POR and a reset.  As Rolf describes his 
>problemit it sounds more like a software issue, since he has a small 
>value resistor between Vcc and GND, which should solve the problem if it 
>were related to POR and incorrectly opeating RESET. Although he has 
>stated that RESET makes no difference, he hasn't said if the no 
>dofference is that it carries on as it was, or resets but exhibits the 
>same behaviour. He also hasn't said how he is determining the that
write 
>works and read doesn't since the only way to really determine this is 
>with a scope to view the I/O lines, and he hasn't done this. assuming 
>the read doesn't work because he doesn't get the expected result
is not 
>good fault finding practice. My main reason for jumping in was because 
>Rolf was jumping to conclusions without adequate evidence. the sort of 
>thing we all experience. As  a hardware guy the programmers always blame 
>your hardware, and as a programmer the hardware guys always blame the 
>code. Without adequate and logical fault finding processes in place you 
>cannot make the assumptions he was.

>Al

>Bill Knight wrote:

>>On Sun, 31 Jul 2005 20:58:05 +0200,
rolf.freitag@rolf... wrote:
>>
>>
>>
>>  
>>
>>>Hi,
>>>    
>>>
>>
>>  
>>
>>>>Time related errors like 
>>>>this are nearly always software related since this is the only
thing 
>>>>which alwasy does exactly the same thing exactly the same way
each time 
>>>>it runs.
>>>>      
>>>>
>>
>>  
>>
>>>it's not uptime related because a reset does not help;
it's supply voltage time related.
>>>After 10 minutes power down it does not work but after 5 hours power
down it works
>>>(for one minute).
>>>    
>>>
>>
>>  
>>
>>>And i'm using a stack checking function which shows that there
is no stack overflow.
>>>    
>>>
>>
>>
>>
>>How about after 5 hours you start the system up.  Then after say 30 secs
of runtime
>>you press RESET and see if the problem happens either 30 secs later or 1
min later.
>>The former would tend to indicate a hardware problem while the latter
would indicate
>>a software issue.
>>
>>Regards
>>-Bill Knight
>>R O SoftWare
>>
>>
>>
>>
>>
>>.
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>> 
>>
>>
>>
>>
>>
>>  
>>




>.

> 
>Yahoo! Groups Links



> 

Hi,

it seems the problem is in the RAM, because after changing the global volatile
variables to (module global)
volatile static variables it works!
Some days ago i could see that for a mutex it's not enough to declare the
variable as volatile; only if declared
as volatile static a variable is really volatile. It's a feature or bug of
mspgcc or optmisation with -O3 (and -Wall). 
And the software has no unused interrupts; i also checked the assembler listing.

But i discovered another problem: 
When i use the UART1 clocked with XT2 communication works fine with 2400, 9600,
115200 and other baud rates
(also with 256 Bytes big packets) but i see errors when i use XT1 (32768 Hz
ACLK) as clock for UART1.
I'm using the values from the manual for 9600 baud for ACLK:

U1TCTL = 0x10;  // transmitter source select = ACLK
UBR01 = 0x03;
UBR11 = 0x00;
UMCTL1 = 0x4a;                  // manual value: 0x4a (baurate calculator: 0x29)

The Bytes do receive the MSP corrupted: The Byte 0x10 is transformed to 0x04 in
8 of 10 cases and in other
Bytes in the other 2 cases.
Setting a lower baud rate of 2400 does not help. The 32768 Hz ACLK are verified
via the ACLK pin (pin 20).

Any ideas?

Regards,

Rolf


msp430@msp4... schrieb am 01.08.05 14:15:08:
> 
> You are correct Al.  I haven't worked with the MSP in a while and
forgot
> about the differences between RESET & POR.  Also about the RESET
problem
> some of the MSPs have exhibited in the past.
> 
> -Bill
> 
> 
> 
> On Mon, 01 Aug 2005 18:58:30 +0930, Onestone wrote:
> 
> >But this isn't what he described, and I would still not discount
the 
> >software since the problem could well be in the restting of the device.

> >there is a diffeence between a POR and a reset.  As Rolf describes his 
> >problemit it sounds more like a software issue, since he has a small 
> >value resistor between Vcc and GND, which should solve the problem if
it 
> >were related to POR and incorrectly opeating RESET. Although he has 
> >stated that RESET makes no difference, he hasn't said if the no 
> >dofference is that it carries on as it was, or resets but exhibits the 
> >same behaviour. He also hasn't said how he is determining the that
write 
> >works and read doesn't since the only way to really determine this
is 
> >with a scope to view the I/O lines, and he hasn't done this.
assuming 
> >the read doesn't work because he doesn't get the expected
result is not 
> >good fault finding practice. My main reason for jumping in was because 
> >Rolf was jumping to conclusions without adequate evidence. the sort of 
> >thing we all experience. As  a hardware guy the programmers always
blame 
> >your hardware, and as a programmer the hardware guys always blame the 
> >code. Without adequate and logical fault finding processes in place you

> >cannot make the assumptions he was.
> 
> >Al
> 
> >Bill Knight wrote:
> 
> >>On Sun, 31 Jul 2005 20:58:05 +0200, rolf.freitag@rolf... wrote:
> >>
> >>
> >>
> >>  
> >>
> >>>Hi,
> >>>    
> >>>
> >>
> >>  
> >>
> >>>>Time related errors like 
> >>>>this are nearly always software related since this is the
only thing 
> >>>>which alwasy does exactly the same thing exactly the same
way each time 
> >>>>it runs.
> >>>>      
> >>>>
> >>
> >>  
> >>
> >>>it's not uptime related because a reset does not help;
it's supply voltage time related.
> >>>After 10 minutes power down it does not work but after 5 hours
power down it works
> >>>(for one minute).
> >>>    
> >>>
> >>
> >>  
> >>
> >>>And i'm using a stack checking function which shows that
there is no stack overflow.
> >>>    
> >>>
> >>
> >>
> >>
> >>How about after 5 hours you start the system up.  Then after say 30
secs of runtime
> >>you press RESET and see if the problem happens either 30 secs later
or 1 min later.
> >>The former would tend to indicate a hardware problem while the
latter would indicate
> >>a software issue.
> >>
> >>Regards
> >>-Bill Knight
> >>R O SoftWare
> >>
> >>
> >>
> >>
> >>
> >>.
> >>
> >> 
> >>Yahoo! Groups Links
> >>
> >>
> >>
> >> 
> >>
> >>
> >>
> >>
> >>
> >>  
> >>
> 
> 
> 
> 
> >.
> 
> > 
> >Yahoo! Groups Links
> 
> 
> 
> > 
> 
> 
> 
> 
> 
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 

--- In msp430@msp4..., rolf.freitag@e... wrote:
> 
> Hi,
> 
> it seems the problem is in the RAM, because after changing the
global volatile variables to (module global)
> volatile static variables it works!
> Some days ago i could see that for a mutex it's not enough to
declare the variable as volatile; only if declared
> as volatile static a variable is really volatile.
It's a feature or
bug of mspgcc or optmisation with -O3 (and -Wall). 
> And the software has no unused interrupts; i also
checked the
assembler listing.

Glad you managed to solve this. What I mean is that, whether you use
them or not every possible interrupt should have a handler written for it.

> 
> But i discovered another problem: 
> When i use the UART1 clocked with XT2 communication works fine with
2400, 9600, 115200 and other baud rates
> (also with 256 Bytes big packets) but i see errors
when i use XT1
(32768 Hz ACLK) as clock for UART1.
> I'm using the values from the manual for 9600
baud for ACLK:
> 
> U1TCTL = 0x10;  // transmitter source select = ACLK
> UBR01 = 0x03;
> UBR11 = 0x00;
> UMCTL1 = 0x4a;                  // manual value: 0x4a (baurate
calculator: 0x29)
> 
> The Bytes do receive the MSP corrupted: The Byte 0x10 is transformed
to 0x04 in 8 of 10 cases and in other
> Bytes in the other 2 cases.
> Setting a lower baud rate of 2400 does not help. The 32768 Hz ACLK
are verified via the ACLK pin (pin 20).
> 
> Any ideas?

Are you using an interrupt system for the UART? If so what other
interrupts are running, especially on TimerA, assuming this is a slow
clocked timer.

Al

> 
> Regards,
> 
> Rolf
> 
> 
> msp430@msp4... schrieb am 01.08.05 14:15:08:
> > 
> > You are correct Al.  I haven't worked with the MSP in a while and
forgot
> > about the differences between RESET &
POR.  Also about the RESET
problem
> > some of the MSPs have exhibited in the past.
> > 
> > -Bill
> > 
> > 
> > 
> > On Mon, 01 Aug 2005 18:58:30 +0930, Onestone wrote:
> > 
> > >But this isn't what he described, and I would still not
discount the 
> > >software since the problem could well be in the restting of the
device. 
> > >there is a diffeence between a POR and a
reset.  As Rolf
describes his 
> > >problemit it sounds more like a software
issue, since he has a small 
> > >value resistor between Vcc and GND, which should solve the
problem if it 
> > >were related to POR and incorrectly
opeating RESET. Although he has 
> > >stated that RESET makes no difference, he hasn't said if the
no 
> > >dofference is that it carries on as it was, or resets but
exhibits the 
> > >same behaviour. He also hasn't said
how he is determining the
that write 
> > >works and read doesn't since the
only way to really determine
this is 
> > >with a scope to view the I/O lines, and
he hasn't done this.
assuming 
> > >the read doesn't work because he
doesn't get the expected result
is not 
> > >good fault finding practice. My main
reason for jumping in was
because 
> > >Rolf was jumping to conclusions without
adequate evidence. the
sort of 
> > >thing we all experience. As  a hardware
guy the programmers
always blame 
> > >your hardware, and as a programmer the
hardware guys always blame
the 
> > >code. Without adequate and logical fault
finding processes in
place you 
> > >cannot make the assumptions he was.
> > 
> > >Al
> > 
> > >Bill Knight wrote:
> > 
> > >>On Sun, 31 Jul 2005 20:58:05 +0200, rolf.freitag@e...
wrote:
> > >>
> > >>
> > >>
> > >>  
> > >>
> > >>>Hi,
> > >>>    
> > >>>
> > >>
> > >>  
> > >>
> > >>>>Time related errors like 
> > >>>>this are nearly always software related since this is
the only
thing 
> > >>>>which alwasy does exactly the
same thing exactly the same way
each time 
> > >>>>it runs.
> > >>>>      
> > >>>>
> > >>
> > >>  
> > >>
> > >>>it's not uptime related because a reset does not
help; it's
supply voltage time related.
> > >>>After 10 minutes power down it
does not work but after 5 hours
power down it works
> > >>>(for one minute).
> > >>>    
> > >>>
> > >>
> > >>  
> > >>
> > >>>And i'm using a stack checking function which shows
that there
is no stack overflow.
> > >>>    
> > >>>
> > >>
> > >>
> > >>
> > >>How about after 5 hours you start the system up.  Then after
say
30 secs of runtime
> > >>you press RESET and see if the
problem happens either 30 secs
later or 1 min later.
> > >>The former would tend to indicate a
hardware problem while the
latter would indicate
> > >>a software issue.
> > >>
> > >>Regards
> > >>-Bill Knight
> > >>R O SoftWare
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>.
> > >>
> > >> 
> > >>Yahoo! Groups Links
> > >>
> > >>
> > >>
> > >> 
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>  
> > >>
> > 
> > 
> > 
> > 
> > >.
> > 
> > > 
> > >Yahoo! Groups Links
> > 
> > 
> > 
> > > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > .
> > 
> >  
> > Yahoo! Groups Links
> > 
> > 
> > 
> >  
> > 
> >

Hi Al,

> What I mean is that, whether you use
> them or not every possible interrupt should have a handler written for it.

that's what i tried to say and what i verified in the assembler listing
file. 


> > But i discovered another problem: 
> > When i use the UART1 clocked with XT2 communication works fine with
> 2400, 9600, 115200 and other baud rates
> > (also with 256 Bytes big packets) but i see errors when i use XT1
> (32768 Hz ACLK) as clock for UART1.
> > I'm using the values from the manual for 9600 baud for ACLK:
> > 
> > U1TCTL = 0x10;  // transmitter source select = ACLK
> > UBR01 = 0x03;
> > UBR11 = 0x00;
> > UMCTL1 = 0x4a;                  // manual value: 0x4a (baurate
> calculator: 0x29)
> > 
> > The Bytes do receive the MSP corrupted: The Byte 0x10 is transformed
> to 0x04 in 8 of 10 cases and in other
> > Bytes in the other 2 cases.
> > Setting a lower baud rate of 2400 does not help. The 32768 Hz ACLK
> are verified via the ACLK pin (pin 20).
> > 
> > Any ideas?
> 
> Are you using an interrupt system for the UART? If so what other
> interrupts are running, especially on TimerA, assuming this is a slow
> clocked timer.

Yes, i'm using an interrupt system for UART1 but all other interrupts,
exept the one
for the I2C EEPROM on the UART0 and the one from the SVS, are disabled.
The UART0 is only used between receiving/transmitting and SVS is inactive
because
the voltage is 0.3 V higher than necessary and buffered with a 1 F goldcap
(+68 uF tantal
+1 uF ceramic).

And at 2400 Baud  there is a new problem, beside the corrupted bytes: Before
transmitting
waiting for a free transmit buffer was done with

while (not(U1TCTL bitand TXEPT)); // wait for empty U1TXBUF

or

while (not(IFG2 bitand UTXIFG1));  // wait for empty U1TXBUF

but both versions do not work at 2400 Baud olthough they do work at 9600 Baud
and higher.
The while loops never ends at 2400 Baud, although nothing is transmitted!

In the current software that's no problem because i'm using half
duplex mode and therefore
the transmit buffer is always empty at that point and both versions are not
necessary (can be deleted).
But it would be nice to have a version which can be used for a full duplex mode.

Any ideas?

Regards,

Rolf

On Mon, Aug 01, 2005 at 05:44:04PM +0200, rolf.freitag@rolf... wrote:

> (also with 256 Bytes big packets) but i see errors
when i use XT1 (32768 Hz ACLK) as clock for UART1.
> I'm using the values from the manual for 9600 baud for ACLK:
> 
> U1TCTL = 0x10;  // transmitter source select = ACLK
> UBR01 = 0x03;

This bug is reported! Download the latest errata, UBR01=3 is not possible
with the 169 (UART is to slow, problmes with the state machine), maybe
this will be fixed in the future.

        Matthias