Reply by Matthias Weingart●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
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 rolf...@...●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
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 Onestone●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 rolf...@...●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 rolf...@...●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 Onestone●August 1, 20052005-08-01
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
>
>
>
>
>
>
>
>
>
>
Reply by Matthias Weingart●August 1, 20052005-08-01
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
Reply by rolf...@...●August 1, 20052005-08-01
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
