I vaguely recall a problem with the UARTs on the 16x series, or some of
them, but I can't remember. Although I've tested them I haven't
ran a
product out with them yet. I can only say I haven't had problems on the
'149.
Sorry. I'll look into it though.
Al
rolf.freitag@rolf... wrote:
>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
>
>
>
>.
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>
I2C EEPROM: Write works, Read not
Started by ●July 30, 2005
Reply by ●August 1, 20052005-08-01
Reply by ●August 1, 20052005-08-01
Hi Matthias,
> > (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.
i have downloaded the datasheet and manual 6 weeks before; where can i find
the latest errata?
I'm using the same code on an F149 without problems several years.
And there is another problem: At 2400 Baud, with
U1TCTL = 0x10; // transmitter source select = ACLK
UBR01 = 0x0d;
UBR11 = 0x00;
UMCTL1 = 0x6d;
the software hangs at waiting for an free transmit buffer. I tried
while (not(IFG2 bitand UTXIFG1)); // wait for empty U1TXBUF;
and
while (not(U1TCTL bitand TXEPT)); // wait for empty U1TXBUF;
Is this the same bug?
Regards,
Rolf
Reply by ●August 1, 20052005-08-01
Hi,
i think i found it in the new errata: Bug US14 in slaz018a.pdf.
But that errata says nothing about lower baud rates and hanging at waiting for a
free output buffer.
I hope there are no bugs at higher baud rates (currently i'm using 1.5
MBaud).
If my parachutes would have so many bugs i would not have survived the last
century ...
By the way: I found another bug in the application note slaa208: Due to the
manual
you must insert a line like this, before changing I2CNDAT, to avoid
unpredictable
behavior:
while ( (1 == I2CBB) and (0 == I2CRM) ); // check before changing I2CNDAT
Regards,
Rolf
msp430@msp4... schrieb am 02.08.05 00:51:24:
>
>
> Hi Matthias,
>
> > > (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.
>
> i have downloaded the datasheet and manual 6 weeks before; where can i find
> the latest errata?
> I'm using the same code on an F149 without problems several years.
>
> And there is another problem: At 2400 Baud, with
>
> U1TCTL = 0x10; // transmitter source select = ACLK
> UBR01 = 0x0d;
> UBR11 = 0x00;
> UMCTL1 = 0x6d;
>
> the software hangs at waiting for an free transmit buffer. I tried
>
> while (not(IFG2 bitand UTXIFG1)); // wait for empty U1TXBUF;
>
> and
>
> while (not(U1TCTL bitand TXEPT)); // wait for empty U1TXBUF;
>
> Is this the same bug?
>
> Regards,
>
> Rolf
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
Reply by ●August 2, 20052005-08-02
rolf.freitag@rolf... wrote: >Hi, > >i think i found it in the new errata: Bug US14 in slaz018a.pdf. >But that errata says nothing about lower baud rates and hanging at waiting for a >free output buffer. >I hope there are no bugs at higher baud rates (currently i'm using 1.5 MBaud). > >If my parachutes would have so many bugs i would not have survived the last >century ... > Buggah! And I got the impression you were just a young sprog, a hundred years old and still parachuting, remarkable! Al > >By the way: I found another bug in the application note slaa208: Due to the manual >you must insert a line like this, before changing I2CNDAT, to avoid unpredictable >behavior: > >while ( (1 == I2CBB) and (0 == I2CRM) ); // check before changing I2CNDAT > >Regards, > >Rolf > >msp430@msp4... schrieb am 02.08.05 00:51:24: > > >>Hi Matthias, >> >> >> >>>>(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. >>> >>> >>i have downloaded the datasheet and manual 6 weeks before; where can i find >>the latest errata? >>I'm using the same code on an F149 without problems several years. >> >>And there is another problem: At 2400 Baud, with >> >>U1TCTL = 0x10; // transmitter source select = ACLK >>UBR01 = 0x0d; >>UBR11 = 0x00; >>UMCTL1 = 0x6d; >> >>the software hangs at waiting for an free transmit buffer. I tried >> >>while (not(IFG2 bitand UTXIFG1)); // wait for empty U1TXBUF; >> >>and >> >>while (not(U1TCTL bitand TXEPT)); // wait for empty U1TXBUF; >> >>Is this the same bug? >> >>Regards, >> >>Rolf >> >> >> >> >>. >> >> >>Yahoo! Groups Links >> >> >> >> >> >> >> >> > > > > > >. > > >Yahoo! Groups Links > > > > > > > > > >
Reply by ●August 2, 20052005-08-02
Could this bug affect the UART vectors also? I am scratching my head here for two days now in trying to understand why. After about 2 minutes of flawless work my project starts to stutter first on RX and then simply refuses to take the UART RX vector until reset... If there is quick fix, and have encountered this phenomenon, please let me know otherwise I will return with more detail. Alex ----- Original Message ----- From: <rolf.freitag@rolf...> To: <msp430@msp4...> Sent: Monday, August 01, 2005 8:05 PM Subject: Re: [msp430] UART bug (was I2C EEPROM: Write works, Read not) > > Hi, > > i think i found it in the new errata: Bug US14 in slaz018a.pdf. > But that errata says nothing about lower baud rates and hanging at waiting for a > free output buffer. > I hope there are no bugs at higher baud rates (currently i'm using 1.5 MBaud). > > If my parachutes would have so many bugs i would not have survived the last > century ... > > By the way: I found another bug in the application note slaa208: Due to the manual > you must insert a line like this, before changing I2CNDAT, to avoid unpredictable > behavior: > > while ( (1 == I2CBB) and (0 == I2CRM) ); // check before changing I2CNDAT > > Regards, > > Rolf > > msp430@msp4... schrieb am 02.08.05 00:51:24: > > > > > > Hi Matthias, > > > > > > (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. > > > > i have downloaded the datasheet and manual 6 weeks before; where can i find > > the latest errata? > > I'm using the same code on an F149 without problems several years. > > > > And there is another problem: At 2400 Baud, with > > > > U1TCTL = 0x10; // transmitter source select = ACLK > > UBR01 = 0x0d; > > UBR11 = 0x00; > > UMCTL1 = 0x6d; > > > > the software hangs at waiting for an free transmit buffer. I tried > > > > while (not(IFG2 bitand UTXIFG1)); // wait for empty U1TXBUF; > > > > and > > > > while (not(U1TCTL bitand TXEPT)); // wait for empty U1TXBUF; > > > > Is this the same bug? > > > > Regards, > > > > Rolf > > > > > > > > > > . > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > . > > > Yahoo! Groups Links > > > > > > > > > > --- > avast! Antivirus: Inbound message clean. > Virus Database (VPS): 0531-0, 08/01/2005 > Tested on: 8/2/2005 8:05:37 AM > avast! - copyright (c) 1988-2005 ALWIL Software. > http://www.avast.com > > >
Reply by ●August 2, 20052005-08-02
Hi, > Could this bug affect the UART vectors also? I am scratching my head here > for two days now in trying to understand why. the detailed bug description says US14 is "Lost character start edge", so you're loosing bytes by loosing interrupts. It also says: "Workaround: None". At 2400 Baud (with ACLK as clock source) i also saw the bug that waiting for a free transmit buffer also does not work. With an HF XT2 quartz and MCLK/SMCLK clock source the UARTs do work well. A workaround would be bit banging for implementing a UART in software. You can find an application note with souce code at msp430.com, but i think without a HF quartz there can be no reliable workaround. Regards, Rolf > After about 2 minutes of flawless work my project starts to stutter first on > RX and then simply refuses to take the UART RX vector until reset... If > there is quick fix, and have encountered this phenomenon, please let me > know otherwise I will return with more detail. > > Alex > > > > > > > > ----- Original Message ----- > From: <rolf.freitag@rolf...> > To: <msp430@msp4...> > Sent: Monday, August 01, 2005 8:05 PM > Subject: Re: [msp430] UART bug (was I2C EEPROM: Write works, Read not) > > > > > > Hi, > > > > i think i found it in the new errata: Bug US14 in slaz018a.pdf. > > But that errata says nothing about lower baud rates and hanging at waiting > for a > > free output buffer. > > I hope there are no bugs at higher baud rates (currently i'm using 1.5 > MBaud). > > > > If my parachutes would have so many bugs i would not have survived the > last > > century ... > > > > By the way: I found another bug in the application note slaa208: Due to > the manual > > you must insert a line like this, before changing I2CNDAT, to avoid > unpredictable > > behavior: > > > > while ( (1 == I2CBB) and (0 == I2CRM) ); // check before changing I2CNDAT > > > > Regards, > > > > Rolf > > > > msp430@msp4... schrieb am 02.08.05 00:51:24: > > > > > > > > > Hi Matthias, > > > > > > > > (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. > > > > > > i have downloaded the datasheet and manual 6 weeks before; where can i > find > > > the latest errata? > > > I'm using the same code on an F149 without problems several years. > > > > > > And there is another problem: At 2400 Baud, with > > > > > > U1TCTL = 0x10; // transmitter source select = ACLK > > > UBR01 = 0x0d; > > > UBR11 = 0x00; > > > UMCTL1 = 0x6d; > > > > > > the software hangs at waiting for an free transmit buffer. I tried > > > > > > while (not(IFG2 bitand UTXIFG1)); // wait for empty U1TXBUF; > > > > > > and > > > > > > while (not(U1TCTL bitand TXEPT)); // wait for empty U1TXBUF; > > > > > > Is this the same bug? > > > > > > Regards, > > > > > > Rolf > > > > > > > > > > > > > > > . > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > . > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > --- > > avast! Antivirus: Inbound message clean. > > Virus Database (VPS): 0531-0, 08/01/2005 > > Tested on: 8/2/2005 8:05:37 AM > > avast! - copyright (c) 1988-2005 ALWIL Software. > > http://www.avast.com > > > > > > > > > > > . > > > Yahoo! Groups Links > > > > > >
Reply by ●August 2, 20052005-08-02
Rolf, I do not loose bytes. The UART ISR simply is not accessed. It is like it does not see the input string of bits (I verified their presence with the scope) or an Interrupt Enable Bit has not been set. I did verify all Interrupt Enable and all UART0 register config, also port 2 and 1 that share these pins, internally and externally, and found all in order... The 430 simply refuses to take the vector after 2-3 minutes. It stutters first, in the sense it takes the ISR every so often and then stops completely... If I would be battery powered I would blame initially this on a depleted battery but the target is powered by the FET and the SCOPE shows 3VDC without glitches.... I think I need to come with more detail for any one in this group to make an educated guess of what it is happening... Alex ----- Original Message ----- From: <rolf.freitag@rolf...> To: <msp430@msp4...> Sent: Tuesday, August 02, 2005 11:55 AM Subject: Re: [msp430] UART bug (was I2C EEPROM: Write works, Read not) C > > Hi, > > > Could this bug affect the UART vectors also? I am scratching my head here > > for two days now in trying to understand why. > > the detailed bug description says US14 is "Lost character start edge", > so you're loosing bytes by loosing interrupts. > It also says: "Workaround: None". > At 2400 Baud (with ACLK as clock source) i also saw the bug that waiting > for a free transmit buffer also does not work. > With an HF XT2 quartz and MCLK/SMCLK clock source the UARTs do > work well. > > A workaround would be bit banging for implementing a UART in software. > You can find an application note with souce code at msp430.com, but i think > without a HF quartz there can be no reliable workaround. > > Regards, > > Rolf > > > > After about 2 minutes of flawless work my project starts to stutter first on > > RX and then simply refuses to take the UART RX vector until reset... If > > there is quick fix, and have encountered this phenomenon, please let me > > know otherwise I will return with more detail. > > > > Alex > > > > > > > > > > > > > > > > ----- Original Message ----- > > From: <rolf.freitag@rolf...> > > To: <msp430@msp4...> > > Sent: Monday, August 01, 2005 8:05 PM > > Subject: Re: [msp430] UART bug (was I2C EEPROM: Write works, Read not) > > > > > > > > > > Hi, > > > > > > i think i found it in the new errata: Bug US14 in slaz018a.pdf. > > > But that errata says nothing about lower baud rates and hanging at waiting > > for a > > > free output buffer. > > > I hope there are no bugs at higher baud rates (currently i'm using 1.5 > > MBaud). > > > > > > If my parachutes would have so many bugs i would not have survived the > > last > > > century ... > > > > > > By the way: I found another bug in the application note slaa208: Due to > > the manual > > > you must insert a line like this, before changing I2CNDAT, to avoid > > unpredictable > > > behavior: > > > > > > while ( (1 == I2CBB) and (0 == I2CRM) ); // check before changing I2CNDAT > > > > > > Regards, > > > > > > Rolf > > > > > > msp430@msp4... schrieb am 02.08.05 00:51:24: > > > > > > > > > > > > Hi Matthias, > > > > > > > > > > (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. > > > > > > > > i have downloaded the datasheet and manual 6 weeks before; where can i > > find > > > > the latest errata? > > > > I'm using the same code on an F149 without problems several years. > > > > > > > > And there is another problem: At 2400 Baud, with > > > > > > > > U1TCTL = 0x10; // transmitter source select = ACLK > > > > UBR01 = 0x0d; > > > > UBR11 = 0x00; > > > > UMCTL1 = 0x6d; > > > > > > > > the software hangs at waiting for an free transmit buffer. I tried > > > > > > > > while (not(IFG2 bitand UTXIFG1)); // wait for empty U1TXBUF; > > > > > > > > and > > > > > > > > while (not(U1TCTL bitand TXEPT)); // wait for empty U1TXBUF; > > > > > > > > Is this the same bug? > > > > > > > > Regards, > > > > > > > > Rolf > > > > > > > > > > > > > > > > > > > > . > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > . > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --- > > > avast! Antivirus: Inbound message clean. > > > Virus Database (VPS): 0531-0, 08/01/2005 > > > Tested on: 8/2/2005 8:05:37 AM > > > avast! - copyright (c) 1988-2005 ALWIL Software. > > > http://www.avast.com > > > > > > > > > > > > > > > > > > > . > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > . > > > Yahoo! Groups Links > > > > > > > > > > --- > avast! Antivirus: Inbound message clean. > Virus Database (VPS): 0531-1, 08/02/2005 > Tested on: 8/2/2005 12:09:06 PM > avast! - copyright (c) 1988-2005 ALWIL Software. > http://www.avast.com > > >
Reply by ●August 2, 20052005-08-02
The US14 is resulting in a not working 9600 baud comms using the 32kHz
xtal.
Workarounds can be: use 4800baud ;-) or use another clock. Without
changing the hardware you can switch to DCO as clck source (synchronized
to ACLK). Drawbacks: you need a free timer and more power - this is not
a good workaround ;-). Same applies for the software uart. Maybe you need
less power.
M.
On Tue, Aug 02, 2005 at 05:55:11PM +0200,
rolf.freitag@rolf... wrote:
>
> Hi,
>
> > Could this bug affect the UART vectors also? I am scratching my head
here
> > for two days now in trying to understand why.
>
> the detailed bug description says US14 is "Lost character start
edge",
> so you're loosing bytes by loosing interrupts.
> It also says: "Workaround: None".
> At 2400 Baud (with ACLK as clock source) i also saw the bug that waiting
> for a free transmit buffer also does not work.
> With an HF XT2 quartz and MCLK/SMCLK clock source the UARTs do
> work well.
>
> A workaround would be bit banging for implementing a UART in software.
> You can find an application note with souce code at msp430.com, but i think
> without a HF quartz there can be no reliable workaround.
>
> Regards,
>
> Rolf
>
>
> > After about 2 minutes of flawless work my project starts to stutter
first on
> > RX and then simply refuses to take the UART RX vector until reset...
If
> > there is quick fix, and have encountered this phenomenon, please let
me
> > know otherwise I will return with more detail.
> >
> > Alex
> >
> >
> >
> >
> >
> >
> >
> > ----- Original Message -----
> > From: <rolf.freitag@rolf...>
> > To: <msp430@msp4...>
> > Sent: Monday, August 01, 2005 8:05 PM
> > Subject: Re: [msp430] UART bug (was I2C EEPROM: Write works, Read not)
> >
> >
> > >
> > > Hi,
> > >
> > > i think i found it in the new errata: Bug US14 in slaz018a.pdf.
> > > But that errata says nothing about lower baud rates and hanging
at waiting
> > for a
> > > free output buffer.
> > > I hope there are no bugs at higher baud rates (currently i'm
using 1.5
> > MBaud).
> > >
> > > If my parachutes would have so many bugs i would not have
survived the
> > last
> > > century ...
> > >
> > > By the way: I found another bug in the application note slaa208:
Due to
> > the manual
> > > you must insert a line like this, before changing I2CNDAT, to
avoid
> > unpredictable
> > > behavior:
> > >
> > > while ( (1 == I2CBB) and (0 == I2CRM) ); // check before changing
I2CNDAT
> > >
> > > Regards,
> > >
> > > Rolf
> > >
> > > msp430@msp4... schrieb am 02.08.05 00:51:24:
> > > >
> > > >
> > > > Hi Matthias,
> > > >
> > > > > > (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.
> > > >
> > > > i have downloaded the datasheet and manual 6 weeks before;
where can i
> > find
> > > > the latest errata?
> > > > I'm using the same code on an F149 without problems
several years.
> > > >
> > > > And there is another problem: At 2400 Baud, with
> > > >
> > > > U1TCTL = 0x10; // transmitter source select = ACLK
> > > > UBR01 = 0x0d;
> > > > UBR11 = 0x00;
> > > > UMCTL1 = 0x6d;
> > > >
> > > > the software hangs at waiting for an free transmit buffer. I
tried
> > > >
> > > > while (not(IFG2 bitand UTXIFG1)); // wait for empty U1TXBUF;
> > > >
> > > > and
> > > >
> > > > while (not(U1TCTL bitand TXEPT)); // wait for empty U1TXBUF;
> > > >
> > > > Is this the same bug?
> > > >
> > > > Regards,
> > > >
> > > > Rolf
> > > >
> > > >
> > > >
> > > >
> > > > .
> > > >
> > > >
> > > > Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > > .
> > >
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---
> > > avast! Antivirus: Inbound message clean.
> > > Virus Database (VPS): 0531-0, 08/01/2005
> > > Tested on: 8/2/2005 8:05:37 AM
> > > avast! - copyright (c) 1988-2005 ALWIL Software.
> > > http://www.avast.com
> > >
> > >
> > >
> >
> >
> >
> >
> > .
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>
>
>
>
>
> .
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
Matthias