Hi all,
Im using the RTC library from TI and using its calendar and RTC functions ... Everything works ok when it comes to time management.. I set up a 1 sec Int using the basic timer.. and the time is ok...

but when i try and set the date .. the month and day values are set incorrectly ..and Ive been goofing around with the code for about an hour now.. Has anyone else encountered this problem with the TI library.. ?
thanks and regards

Umer

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I assume that this is the RTC library for the F5438 family. This was IIRC
hand crafted to get around the problems with the RTC silicon in the F5x
processors. I tried to use the RTC hardware but found that, as you have,
the date often failed to update correctly when I set it. The fallback was
to use the software RTC that I had used in the F1x and F2x products. There
was not time to debug this problem.

Ian

2009/9/29 umer

> Hi all,
> Im using the RTC library from TI and using its calendar and RTC functions
> ... Everything works ok when it comes to time management.. I set up a 1 sec
> Int using the basic timer.. and the time is ok...
>
> but when i try and set the date .. the month and day values are set
> incorrectly ..and Ive been goofing around with the code for about an hour
> now.. Has anyone else encountered this problem with the TI library.. ?
> thanks and regards
>
> Umer
>
> ------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

everything seems to work fine with the hand crafted library (I use it with =
crossworks so some minor changes needed to be made to be compatible), many =
of the bugs in the 54xx silicon have been fixed on the 5529.. I have been p=
laying with it lately and have been pleasently surprised..
=A0
=A0
--- On Tue, 9/29/09, Ian Okey wrote:
From: Ian Okey
Subject: Re: [msp430] Using the RTC library from TI
To: m...@yahoogroups.com
Date: Tuesday, September 29, 2009, 4:26 AM
=A0=20

I assume that this is the RTC library for the F5438 family. This was IIRC
hand crafted to get around the problems with the RTC silicon in the F5x
processors. I tried to use the RTC hardware but found that, as you have,
the date often failed to update correctly when I set it. The fallback was
to use the software RTC that I had used in the F1x and F2x products. There
was not time to debug this problem.

Ian

2009/9/29 umer

> Hi all,
> Im using the RTC library from TI and using its calendar and RTC functions
> ... Everything works ok when it comes to time management.. I set up a 1 s=
ec
> Int using the basic timer.. and the time is ok...
>
> but when i try and set the date .. the month and day values are set
> incorrectly ..and Ive been goofing around with the code for about an hour
> now.. Has anyone else encountered this problem with the TI library.. ?
> thanks and regards
>
> Umer
>
> ------------ --------- --------- ------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

"... many of the bugs in the 54xx silicon have been fixed on the 5529.. "=20

Do you have the MSP430F5529 or the XMS430F5529? What is the silicon rev.?

--- In m...@yahoogroups.com, Joe Radomski wrote:
>
> everything seems to work fine with the hand crafted library (I use it wit=
h crossworks so some minor changes needed to be made to be compatible), man=
y of the bugs in the 54xx silicon have been fixed on the 5529.. I have been=
playing with it lately and have been pleasently surprised..
> =A0
> =A0
>=20
>=20
> --- On Tue, 9/29/09, Ian Okey wrote:
>=20
>=20
> From: Ian Okey
> Subject: Re: [msp430] Using the RTC library from TI
> To: m...@yahoogroups.com
> Date: Tuesday, September 29, 2009, 4:26 AM
>=20
>=20
> =A0=20
>=20
>=20
>=20
> I assume that this is the RTC library for the F5438 family. This was IIRC
> hand crafted to get around the problems with the RTC silicon in the F5x
> processors. I tried to use the RTC hardware but found that, as you have,
> the date often failed to update correctly when I set it. The fallback was
> to use the software RTC that I had used in the F1x and F2x products. Ther=
e
> was not time to debug this problem.
>=20
> Ian
>=20
> 2009/9/29 umer
>=20
> > Hi all,
> >
> >
> > Im using the RTC library from TI and using its calendar and RTC functio=
ns
> > ... Everything works ok when it comes to time management.. I set up a 1=
sec
> > Int using the basic timer.. and the time is ok...
> >
> > but when i try and set the date .. the month and day values are set
> > incorrectly ..and Ive been goofing around with the code for about an ho=
ur
> > now.. Has anyone else encountered this problem with the TI library.. ?
> >
> >
> > thanks and regards
> >
> > Umer
> >
> >
> >
> > ------------ --------- --------- ------
> >
> >
> >
> >



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

only=A0 xms rev, but so far things look very good.. I havent verified that =
all the=A0bugs from the 5438 that arent listed n the bug sheet for the 5529=
, but the ones I did look at appear to be fixed. So far no apparant problem=
s with the rtc either.. I am hoping that a few more get fixed by the time i=
t becomes a TMS part..=A0 I havet used the debugger that much so I can't co=
mment there... my only complaint is that they changed the pin out functions=
so much.. I think they should have tried to keep it closer to the 54xx ser=
ies.. makes migrating working code an unnecessary=A0PITA
=A0
What would be reallly cool is if TI added to their parts a true crossbar sw=
itch (nt just the simple alt function of certain pins)=A0so that pins could=
be routed internally as one wished like some of the silabs parts.
=A0
=A0
=A0
=A0
=A0

--- On Tue, 9/29/09, old_cow_yellow wrote:
From: old_cow_yellow
Subject: [msp430] Re: Using the RTC library from TI
To: m...@yahoogroups.com
Date: Tuesday, September 29, 2009, 10:35 AM
=A0=20

"... many of the bugs in the 54xx silicon have been fixed on the 5529.. "=20

Do you have the MSP430F5529 or the XMS430F5529? What is the silicon rev.?

--- In msp430@yahoogroups. com, Joe Radomski wrote:
>
> everything seems to work fine with the hand crafted library (I use it wit=
h crossworks so some minor changes needed to be made to be compatible), man=
y of the bugs in the 54xx silicon have been fixed on the 5529.. I have been=
playing with it lately and have been pleasently surprised..
> =A0
> =A0
>=20
>=20
> --- On Tue, 9/29/09, Ian Okey wrote:
>=20
>=20
> From: Ian Okey
> Subject: Re: [msp430] Using the RTC library from TI
> To: msp430@yahoogroups. com
> Date: Tuesday, September 29, 2009, 4:26 AM
>=20
>=20
> =A0=20
>=20
>=20
>=20
> I assume that this is the RTC library for the F5438 family. This was IIRC
> hand crafted to get around the problems with the RTC silicon in the F5x
> processors. I tried to use the RTC hardware but found that, as you have,
> the date often failed to update correctly when I set it. The fallback was
> to use the software RTC that I had used in the F1x and F2x products. Ther=
e
> was not time to debug this problem.
>=20
> Ian
>=20
> 2009/9/29 umer
>=20
> > Hi all,
> >
> >
> > Im using the RTC library from TI and using its calendar and RTC functio=
ns
> > ... Everything works ok when it comes to time management.. I set up a 1=
sec
> > Int using the basic timer.. and the time is ok...
> >
> > but when i try and set the date .. the month and day values are set
> > incorrectly ..and Ive been goofing around with the code for about an ho=
ur
> > now.. Has anyone else encountered this problem with the TI library.. ?
> >
> >
> > thanks and regards
> >
> > Umer
> >
> >
> >
> > ------------ --------- --------- ------
> >
> >
> >
> >



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

What would be reallly cool is if TI added to their parts a true crossbar
> switch (nt just the simple alt function of certain pins) so that pins could
> be routed internally as one wished like some of the silabs parts.
The trouble is, as ever, these really cool things cost. TI's design aim
with the MSP is to keep power consumption low. That is their competitive
edge. Adding all of this user configurable pin routing adds transistors and
forces non optimal pin configurations all of which burn extra microamps.

Being really honest, how often do you have to reconfigure the device pinning
DURING THE PRODUCT OPERATION. Using the crossbar switch to get round bad
pin selection decisions made at design/layout time is really not good
design.

Ian
[Non-text portions of this message have been removed]

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi all,

I'm trying to work out why at 9600 baud my comms isn't working, but at 115200 it is.
I have a 3.6864Mhz crystal on XT1 of a '156 device.

Code:

/* XT2 off, LFXT1 Mode = Hi Freq, ACLK / 1 (3.6864 MHz) */
BCSCTL1 = XT2OFF + XTS + DIVA_0;

/* selm0 + sem1 selects MCLK source as LFXT1CLK (i.e. 3.6864MHz). MCLK divided by 2 */
BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;

/* USART setup */
UCTL0 = CHAR+SPB; /* 8-bit character, no parity, 2 stop bits */
UTCTL0 |= SSEL0; /* UCLK = ACLK */
UBR00 = 0x80; /* 3.68Mhz/9600 = 383 (low byte) */
UBR10 = 0x01; /* high byte */

UMCTL0 = 0x00; /* no modulation */
ME1 |= UTXE0 + URXE0; /* Enable USART0 TXD/RXD */
IE1 |= URXIE0; /* Enable USART0 RX interrupt */
P3SEL |= 0x30; /* P3.4,5 = USART0 TXD/RXD */
P3DIR |= 0x10; /* P3.4 output direction */

Can anyone tell me the above doesn't work at 9600, whereas if I set:

UBR00 = 0x20;
UBR10 = 0x00; /* high byte */

This does work at 115200 baud!!?

Any hints appreciated!

Thanks

Regards,
Darren

________________________________
This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.

If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
[Non-text portions of this message have been removed]

------------------------------------

______________________________
LaunchPad Kit for MSP430 Value Line: Complete open source tool for harnessing 16-bit performance and ultra-low power. Click for Details


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

One more thing:

If I use the following setup:

//BCSCTL2 = SELS; /* Basic clock system control 2. THIS WORKED TO BEGIN @ 9600 BAUD */

Then 9600 baud does work!!

I get confused over all the clock configurations!!

Vbr,
Darren

From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of Darren Logan
Sent: 30 September 2009 09:46
To: m...@yahoogroups.com
Subject: [msp430] UART baud rate weirdness!
Importance: High

Hi all,

I'm trying to work out why at 9600 baud my comms isn't working, but at 115200 it is.
I have a 3.6864Mhz crystal on XT1 of a '156 device.

Code:

/* XT2 off, LFXT1 Mode = Hi Freq, ACLK / 1 (3.6864 MHz) */
BCSCTL1 = XT2OFF + XTS + DIVA_0;

/* selm0 + sem1 selects MCLK source as LFXT1CLK (i.e. 3.6864MHz). MCLK divided by 2 */
BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;

/* USART setup */
UCTL0 = CHAR+SPB; /* 8-bit character, no parity, 2 stop bits */
UTCTL0 |= SSEL0; /* UCLK = ACLK */
UBR00 = 0x80; /* 3.68Mhz/9600 = 383 (low byte) */
UBR10 = 0x01; /* high byte */

UMCTL0 = 0x00; /* no modulation */
ME1 |= UTXE0 + URXE0; /* Enable USART0 TXD/RXD */
IE1 |= URXIE0; /* Enable USART0 RX interrupt */
P3SEL |= 0x30; /* P3.4,5 = USART0 TXD/RXD */
P3DIR |= 0x10; /* P3.4 output direction */

Can anyone tell me the above doesn't work at 9600, whereas if I set:

UBR00 = 0x20;
UBR10 = 0x00; /* high byte */

This does work at 115200 baud!!?

Any hints appreciated!

Thanks

Regards,
Darren

________________________________
This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.

If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.

[Non-text portions of this message have been removed]
________________________________
This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.

If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
[Non-text portions of this message have been removed]

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Good decisions at the start are important, In the past I saw no reason as T=
I tried to keep pinouts and function assignments fairly consistent and made=
part upgrading quite painless, but lately they keep massively changing the=
pins and making changing to better devices a PITA..=A0 There seems to be n=
o rhyme or reason to their recent pin swapping..
=A0
going from say a 16x to a 26x wasnt that bad pinout was compatible just had=
to support the new modules.. going from the 26x to the 54xx was more of a =
pain (mostly same modules but alot of pin changes) going from a 54xx to a 5=
5xx is even worse.. its one thing to just change pin numbers but TI has bee=
n changing the function assignments as well and in some cases splitting the=
m over different ports.. If they arent going to be consistent they should a=
t least have a mechanism to make it easy for the designer to change parts a=
s need or improvements come to fruition.. These parts are in the same famil=
y, so it would be logical to keep parts with the same pin count as close as=
possible, every other manufacturer does.. I think its very short sided on =
TI's part
=A0
--- On Wed, 9/30/09, Ian Okey wrote:
From: Ian Okey
Subject: Re: [msp430] Re: Using the RTC library from TI
To: m...@yahoogroups.com
Date: Wednesday, September 30, 2009, 4:09 AM
=A0=20

What would be reallly cool is if TI added to their parts a true crossbar
> switch (nt just the simple alt function of certain pins) so that pins cou=
ld
> be routed internally as one wished like some of the silabs parts.
The trouble is, as ever, these really cool things cost. TI's design aim
with the MSP is to keep power consumption low. That is their competitive
edge. Adding all of this user configurable pin routing adds transistors and
forces non optimal pin configurations all of which burn extra microamps.

Being really honest, how often do you have to reconfigure the device pinnin=
g
DURING THE PRODUCT OPERATION. Using the crossbar switch to get round bad
pin selection decisions made at design/layout time is really not good
design.

Ian

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

What do you mean it doesn't work?! What doesn't work?
It might not even have anything to do with the UART hardware but with the software that uses the much slower baud rate (timer expiration?).
Did you set the slower baudrate on the other device too?
Or maybe you haven't disabled the watchdog!

Michael K.

--- In m...@yahoogroups.com, Darren Logan wrote:
>
> One more thing:
>
> If I use the following setup:
>
> //BCSCTL2 = SELS; /* Basic clock system control 2. THIS WORKED TO BEGIN @ 9600 BAUD */
>
> Then 9600 baud does work!!
>
> I get confused over all the clock configurations!!
>
> Vbr,
> Darren
>
> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of Darren Logan
> Sent: 30 September 2009 09:46
> To: m...@yahoogroups.com
> Subject: [msp430] UART baud rate weirdness!
> Importance: High
>
> Hi all,
>
> I'm trying to work out why at 9600 baud my comms isn't working, but at 115200 it is.
> I have a 3.6864Mhz crystal on XT1 of a '156 device.
>
> Code:
>
> /* XT2 off, LFXT1 Mode = Hi Freq, ACLK / 1 (3.6864 MHz) */
> BCSCTL1 = XT2OFF + XTS + DIVA_0;
>
> /* selm0 + sem1 selects MCLK source as LFXT1CLK (i.e. 3.6864MHz). MCLK divided by 2 */
> BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;
>
> /* USART setup */
> UCTL0 = CHAR+SPB; /* 8-bit character, no parity, 2 stop bits */
> UTCTL0 |= SSEL0; /* UCLK = ACLK */
> UBR00 = 0x80; /* 3.68Mhz/9600 = 383 (low byte) */
> UBR10 = 0x01; /* high byte */
>
> UMCTL0 = 0x00; /* no modulation */
> ME1 |= UTXE0 + URXE0; /* Enable USART0 TXD/RXD */
> IE1 |= URXIE0; /* Enable USART0 RX interrupt */
> P3SEL |= 0x30; /* P3.4,5 = USART0 TXD/RXD */
> P3DIR |= 0x10; /* P3.4 output direction */
>
> Can anyone tell me the above doesn't work at 9600, whereas if I set:
>
> UBR00 = 0x20;
> UBR10 = 0x00; /* high byte */
>
> This does work at 115200 baud!!?
>
> Any hints appreciated!
>
> Thanks
>
> Regards,
> Darren
>
> ________________________________
> This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
>
> If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
>
> [Non-text portions of this message have been removed]
> ________________________________
> This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
>
> If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> [Non-text portions of this message have been removed]
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

There are all kinds of possible problems. It takes much longer time for 9600 to "work". Did you wait for flags?

--- In m...@yahoogroups.com, "Michael" wrote:
>
> What do you mean it doesn't work?! What doesn't work?
> It might not even have anything to do with the UART hardware but with the software that uses the much slower baud rate (timer expiration?).
> Did you set the slower baudrate on the other device too?
> Or maybe you haven't disabled the watchdog!
>
> Michael K.
>
> --- In m...@yahoogroups.com, Darren Logan wrote:
> >
> > One more thing:
> >
> > If I use the following setup:
> >
> > //BCSCTL2 = SELS; /* Basic clock system control 2. THIS WORKED TO BEGIN @ 9600 BAUD */
> >
> > Then 9600 baud does work!!
> >
> > I get confused over all the clock configurations!!
> >
> > Vbr,
> > Darren
> >
> > From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of Darren Logan
> > Sent: 30 September 2009 09:46
> > To: m...@yahoogroups.com
> > Subject: [msp430] UART baud rate weirdness!
> > Importance: High
> >
> >
> >
> > Hi all,
> >
> > I'm trying to work out why at 9600 baud my comms isn't working, but at 115200 it is.
> > I have a 3.6864Mhz crystal on XT1 of a '156 device.
> >
> > Code:
> >
> > /* XT2 off, LFXT1 Mode = Hi Freq, ACLK / 1 (3.6864 MHz) */
> > BCSCTL1 = XT2OFF + XTS + DIVA_0;
> >
> > /* selm0 + sem1 selects MCLK source as LFXT1CLK (i.e. 3.6864MHz). MCLK divided by 2 */
> > BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;
> >
> > /* USART setup */
> > UCTL0 = CHAR+SPB; /* 8-bit character, no parity, 2 stop bits */
> > UTCTL0 |= SSEL0; /* UCLK = ACLK */
> > UBR00 = 0x80; /* 3.68Mhz/9600 = 383 (low byte) */
> > UBR10 = 0x01; /* high byte */
> >
> > UMCTL0 = 0x00; /* no modulation */
> > ME1 |= UTXE0 + URXE0; /* Enable USART0 TXD/RXD */
> > IE1 |= URXIE0; /* Enable USART0 RX interrupt */
> > P3SEL |= 0x30; /* P3.4,5 = USART0 TXD/RXD */
> > P3DIR |= 0x10; /* P3.4 output direction */
> >
> > Can anyone tell me the above doesn't work at 9600, whereas if I set:
> >
> > UBR00 = 0x20;
> > UBR10 = 0x00; /* high byte */
> >
> > This does work at 115200 baud!!?
> >
> > Any hints appreciated!
> >
> > Thanks
> >
> > Regards,
> > Darren
> >
> > ________________________________
> > This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
> >
> > If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> >
> > [Non-text portions of this message have been removed]
> >
> >
> > ________________________________
> > This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
> >
> > If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> >
> >
> > [Non-text portions of this message have been removed]
>

------------------------------------

______________________________
LaunchPad Kit for MSP430 Value Line: Complete open source tool for harnessing 16-bit performance and ultra-low power. Click for Details


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Hi,

Thanks for pointing out the obvious (setting the other device baud rate) - I'm not that stupid!
(although arguably I am a little bit stupid)

Sorry - what I mean by work and not work is I'm using modBUS. By not working I mean I get no
response on my modbus master (PC).

What I don't understand is why does the 115200 baud works, yet 9600 doesn't on the same clock configuration.

The firmware starts with the baud set to 9600, but with this:
BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;

I get no response, yet with this:
BCSCTL2 = SELS;

9600 baud does work.

It seems that the MSP is receiving the correct command at 9600. It's the response from the MSP that
isn't correct.

Thanks

Darren

From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of old_cow_yellow
Sent: 30 September 2009 16:17
To: m...@yahoogroups.com
Subject: [msp430] Re: UART baud rate weirdness!

There are all kinds of possible problems. It takes much longer time for 9600 to "work". Did you wait for flags?

--- In m...@yahoogroups.com, "Michael" wrote:
>
> What do you mean it doesn't work?! What doesn't work?
> It might not even have anything to do with the UART hardware but with the software that uses the much slower baud rate (timer expiration?).
> Did you set the slower baudrate on the other device too?
> Or maybe you haven't disabled the watchdog!
>
> Michael K.
>
> --- In m...@yahoogroups.com, Darren Logan wrote:
> >
> > One more thing:
> >
> > If I use the following setup:
> >
> > //BCSCTL2 = SELS; /* Basic clock system control 2. THIS WORKED TO BEGIN @ 9600 BAUD */
> >
> > Then 9600 baud does work!!
> >
> > I get confused over all the clock configurations!!
> >
> > Vbr,
> > Darren
> >
> > From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of Darren Logan
> > Sent: 30 September 2009 09:46
> > To: m...@yahoogroups.com
> > Subject: [msp430] UART baud rate weirdness!
> > Importance: High
> >
> >
> >
> > Hi all,
> >
> > I'm trying to work out why at 9600 baud my comms isn't working, but at 115200 it is.
> > I have a 3.6864Mhz crystal on XT1 of a '156 device.
> >
> > Code:
> >
> > /* XT2 off, LFXT1 Mode = Hi Freq, ACLK / 1 (3.6864 MHz) */
> > BCSCTL1 = XT2OFF + XTS + DIVA_0;
> >
> > /* selm0 + sem1 selects MCLK source as LFXT1CLK (i.e. 3.6864MHz). MCLK divided by 2 */
> > BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;
> >
> > /* USART setup */
> > UCTL0 = CHAR+SPB; /* 8-bit character, no parity, 2 stop bits */
> > UTCTL0 |= SSEL0; /* UCLK = ACLK */
> > UBR00 = 0x80; /* 3.68Mhz/9600 = 383 (low byte) */
> > UBR10 = 0x01; /* high byte */
> >
> > UMCTL0 = 0x00; /* no modulation */
> > ME1 |= UTXE0 + URXE0; /* Enable USART0 TXD/RXD */
> > IE1 |= URXIE0; /* Enable USART0 RX interrupt */
> > P3SEL |= 0x30; /* P3.4,5 = USART0 TXD/RXD */
> > P3DIR |= 0x10; /* P3.4 output direction */
> >
> > Can anyone tell me the above doesn't work at 9600, whereas if I set:
> >
> > UBR00 = 0x20;
> > UBR10 = 0x00; /* high byte */
> >
> > This does work at 115200 baud!!?
> >
> > Any hints appreciated!
> >
> > Thanks
> >
> > Regards,
> > Darren
> >
> > ________________________________
> > This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
> >
> > If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> >
> > [Non-text portions of this message have been removed]
> >
> >
> > ________________________________
> > This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
> >
> > If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> >
> >
> > [Non-text portions of this message have been removed]
>

________________________________
This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.

If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
[Non-text portions of this message have been removed]

------------------------------------

______________________________
LaunchPad Kit for MSP430 Value Line: Complete open source tool for harnessing 16-bit performance and ultra-low power. Click for Details


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I know some teenagers, who can drive at 100 mile/hr "without any problem". But they got all kinds of problems at 35 mile/hr. They ignore stop signs and traffic lights.

--- In m...@yahoogroups.com, Darren Logan wrote:
>
> Hi,
>
> Thanks for pointing out the obvious (setting the other device baud rate) - I'm not that stupid!
> (although arguably I am a little bit stupid)
>
> Sorry - what I mean by work and not work is I'm using modBUS. By not working I mean I get no
> response on my modbus master (PC).
>
> What I don't understand is why does the 115200 baud works, yet 9600 doesn't on the same clock configuration.
>
> The firmware starts with the baud set to 9600, but with this:
> BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;
>
> I get no response, yet with this:
> BCSCTL2 = SELS;
>
> 9600 baud does work.
>
> It seems that the MSP is receiving the correct command at 9600. It's the response from the MSP that
> isn't correct.
>
> Thanks
>
> Darren
>
> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of old_cow_yellow
> Sent: 30 September 2009 16:17
> To: m...@yahoogroups.com
> Subject: [msp430] Re: UART baud rate weirdness!
>
> There are all kinds of possible problems. It takes much longer time for 9600 to "work". Did you wait for flags?
>
> --- In m...@yahoogroups.com, "Michael" wrote:
> >
> > What do you mean it doesn't work?! What doesn't work?
> > It might not even have anything to do with the UART hardware but with the software that uses the much slower baud rate (timer expiration?).
> > Did you set the slower baudrate on the other device too?
> > Or maybe you haven't disabled the watchdog!
> >
> > Michael K.
> >
> > --- In m...@yahoogroups.com, Darren Logan wrote:
> > >
> > > One more thing:
> > >
> > > If I use the following setup:
> > >
> > > //BCSCTL2 = SELS; /* Basic clock system control 2. THIS WORKED TO BEGIN @ 9600 BAUD */
> > >
> > > Then 9600 baud does work!!
> > >
> > > I get confused over all the clock configurations!!
> > >
> > > Vbr,
> > > Darren
> > >
> > > From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of Darren Logan
> > > Sent: 30 September 2009 09:46
> > > To: m...@yahoogroups.com
> > > Subject: [msp430] UART baud rate weirdness!
> > > Importance: High
> > >
> > >
> > >
> > > Hi all,
> > >
> > > I'm trying to work out why at 9600 baud my comms isn't working, but at 115200 it is.
> > > I have a 3.6864Mhz crystal on XT1 of a '156 device.
> > >
> > > Code:
> > >
> > > /* XT2 off, LFXT1 Mode = Hi Freq, ACLK / 1 (3.6864 MHz) */
> > > BCSCTL1 = XT2OFF + XTS + DIVA_0;
> > >
> > > /* selm0 + sem1 selects MCLK source as LFXT1CLK (i.e. 3.6864MHz). MCLK divided by 2 */
> > > BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;
> > >
> > > /* USART setup */
> > > UCTL0 = CHAR+SPB; /* 8-bit character, no parity, 2 stop bits */
> > > UTCTL0 |= SSEL0; /* UCLK = ACLK */
> > > UBR00 = 0x80; /* 3.68Mhz/9600 = 383 (low byte) */
> > > UBR10 = 0x01; /* high byte */
> > >
> > > UMCTL0 = 0x00; /* no modulation */
> > > ME1 |= UTXE0 + URXE0; /* Enable USART0 TXD/RXD */
> > > IE1 |= URXIE0; /* Enable USART0 RX interrupt */
> > > P3SEL |= 0x30; /* P3.4,5 = USART0 TXD/RXD */
> > > P3DIR |= 0x10; /* P3.4 output direction */
> > >
> > > Can anyone tell me the above doesn't work at 9600, whereas if I set:
> > >
> > > UBR00 = 0x20;
> > > UBR10 = 0x00; /* high byte */
> > >
> > > This does work at 115200 baud!!?
> > >
> > > Any hints appreciated!
> > >
> > > Thanks
> > >
> > > Regards,
> > > Darren
> > >
> > > ________________________________
> > > This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
> > >
> > > If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > > ________________________________
> > > This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
> > >
> > > If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> ________________________________
> This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
>
> If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> [Non-text portions of this message have been removed]
>

------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

There are very few teenagers with the experience to drive safely at
100mph. they only think they can. You only need to visit the morgues and
spinal injury wards to understand this sad fact of life. It's 'no
problem' to drive that fast, any moron can do it, it's a whole different
ball game to be able to do it safely. Of course the flip side to the
coin is that on long boring highway drives it's almost as dangerous to
drive too slowly, and out nanny society still insists on killing people
by enforcing stupidly low speed limits.

Al

old_cow_yellow wrote:
> I know some teenagers, who can drive at 100 mile/hr "without any problem". But they got all kinds of problems at 35 mile/hr. They ignore stop signs and traffic lights.
>
> --- In m...@yahoogroups.com, Darren Logan wrote:
>> Hi,
>>
>> Thanks for pointing out the obvious (setting the other device baud rate) - I'm not that stupid!
>> (although arguably I am a little bit stupid)
>>
>> Sorry - what I mean by work and not work is I'm using modBUS. By not working I mean I get no
>> response on my modbus master (PC).
>>
>> What I don't understand is why does the 115200 baud works, yet 9600 doesn't on the same clock configuration.
>>
>> The firmware starts with the baud set to 9600, but with this:
>> BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;
>>
>> I get no response, yet with this:
>> BCSCTL2 = SELS;
>>
>> 9600 baud does work.
>>
>> It seems that the MSP is receiving the correct command at 9600. It's the response from the MSP that
>> isn't correct.
>>
>> Thanks
>>
>> Darren
>>
>> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of old_cow_yellow
>> Sent: 30 September 2009 16:17
>> To: m...@yahoogroups.com
>> Subject: [msp430] Re: UART baud rate weirdness!
>>
>> There are all kinds of possible problems. It takes much longer time for 9600 to "work". Did you wait for flags?
>>
>> --- In m...@yahoogroups.com, "Michael" wrote:
>>> What do you mean it doesn't work?! What doesn't work?
>>> It might not even have anything to do with the UART hardware but with the software that uses the much slower baud rate (timer expiration?).
>>> Did you set the slower baudrate on the other device too?
>>> Or maybe you haven't disabled the watchdog!
>>>
>>> Michael K.
>>>
>>> --- In m...@yahoogroups.com, Darren Logan wrote:
>>>> One more thing:
>>>>
>>>> If I use the following setup:
>>>>
>>>> //BCSCTL2 = SELS; /* Basic clock system control 2. THIS WORKED TO BEGIN @ 9600 BAUD */
>>>>
>>>> Then 9600 baud does work!!
>>>>
>>>> I get confused over all the clock configurations!!
>>>>
>>>> Vbr,
>>>> Darren
>>>>
>>>> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of Darren Logan
>>>> Sent: 30 September 2009 09:46
>>>> To: m...@yahoogroups.com
>>>> Subject: [msp430] UART baud rate weirdness!
>>>> Importance: High
>>>>
>>>>
>>>>
>>>> Hi all,
>>>>
>>>> I'm trying to work out why at 9600 baud my comms isn't working, but at 115200 it is.
>>>> I have a 3.6864Mhz crystal on XT1 of a '156 device.
>>>>
>>>> Code:
>>>>
>>>> /* XT2 off, LFXT1 Mode = Hi Freq, ACLK / 1 (3.6864 MHz) */
>>>> BCSCTL1 = XT2OFF + XTS + DIVA_0;
>>>>
>>>> /* selm0 + sem1 selects MCLK source as LFXT1CLK (i.e. 3.6864MHz). MCLK divided by 2 */
>>>> BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;
>>>>
>>>> /* USART setup */
>>>> UCTL0 = CHAR+SPB; /* 8-bit character, no parity, 2 stop bits */
>>>> UTCTL0 |= SSEL0; /* UCLK = ACLK */
>>>> UBR00 = 0x80; /* 3.68Mhz/9600 = 383 (low byte) */
>>>> UBR10 = 0x01; /* high byte */
>>>>
>>>> UMCTL0 = 0x00; /* no modulation */
>>>> ME1 |= UTXE0 + URXE0; /* Enable USART0 TXD/RXD */
>>>> IE1 |= URXIE0; /* Enable USART0 RX interrupt */
>>>> P3SEL |= 0x30; /* P3.4,5 = USART0 TXD/RXD */
>>>> P3DIR |= 0x10; /* P3.4 output direction */
>>>>
>>>> Can anyone tell me the above doesn't work at 9600, whereas if I set:
>>>>
>>>> UBR00 = 0x20;
>>>> UBR10 = 0x00; /* high byte */
>>>>
>>>> This does work at 115200 baud!!?
>>>>
>>>> Any hints appreciated!
>>>>
>>>> Thanks
>>>>
>>>> Regards,
>>>> Darren
>>>>
>>>> ________________________________
>>>> This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
>>>>
>>>> If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
>>>>
>>>> [Non-text portions of this message have been removed]
>>>>
>>>>
>>>> ________________________________
>>>> This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
>>>>
>>>> If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
>>>>
>>>>
>>>> [Non-text portions of this message have been removed]
>>>> ________________________________
>> This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
>>
>> If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
>> [Non-text portions of this message have been removed]
>>
> ------------------------------------



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

As always, I'm appreciative of the wit and humour which prevails on this list.

You guys... ya just SO funny.

Meanwhile, I've found the problem.

I have a delay() routine which is dependant on the MCLK. This delay is used between switching my
RS485 device to/from input/output.
By changing the clock, I've changed my delays - which in turn "clipped" some of the outgoing data from the MSP.

I've adjusted my delays.

Sorted. :)

From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of old_cow_yellow
Sent: 30 September 2009 23:14
To: m...@yahoogroups.com
Subject: [msp430] Re: UART baud rate weirdness!

I know some teenagers, who can drive at 100 mile/hr "without any problem". But they got all kinds of problems at 35 mile/hr. They ignore stop signs and traffic lights.

--- In m...@yahoogroups.com, Darren Logan wrote:
>
> Hi,
>
> Thanks for pointing out the obvious (setting the other device baud rate) - I'm not that stupid!
> (although arguably I am a little bit stupid)
>
> Sorry - what I mean by work and not work is I'm using modBUS. By not working I mean I get no
> response on my modbus master (PC).
>
> What I don't understand is why does the 115200 baud works, yet 9600 doesn't on the same clock configuration.
>
> The firmware starts with the baud set to 9600, but with this:
> BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;
>
> I get no response, yet with this:
> BCSCTL2 = SELS;
>
> 9600 baud does work.
>
> It seems that the MSP is receiving the correct command at 9600. It's the response from the MSP that
> isn't correct.
>
> Thanks
>
> Darren
>
> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of old_cow_yellow
> Sent: 30 September 2009 16:17
> To: m...@yahoogroups.com
> Subject: [msp430] Re: UART baud rate weirdness!
>
> There are all kinds of possible problems. It takes much longer time for 9600 to "work". Did you wait for flags?
>
> --- In m...@yahoogroups.com, "Michael" wrote:
> >
> > What do you mean it doesn't work?! What doesn't work?
> > It might not even have anything to do with the UART hardware but with the software that uses the much slower baud rate (timer expiration?).
> > Did you set the slower baudrate on the other device too?
> > Or maybe you haven't disabled the watchdog!
> >
> > Michael K.
> >
> > --- In m...@yahoogroups.com, Darren Logan wrote:
> > >
> > > One more thing:
> > >
> > > If I use the following setup:
> > >
> > > //BCSCTL2 = SELS; /* Basic clock system control 2. THIS WORKED TO BEGIN @ 9600 BAUD */
> > >
> > > Then 9600 baud does work!!
> > >
> > > I get confused over all the clock configurations!!
> > >
> > > Vbr,
> > > Darren
> > >
> > > From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of Darren Logan
> > > Sent: 30 September 2009 09:46
> > > To: m...@yahoogroups.com
> > > Subject: [msp430] UART baud rate weirdness!
> > > Importance: High
> > >
> > >
> > >
> > > Hi all,
> > >
> > > I'm trying to work out why at 9600 baud my comms isn't working, but at 115200 it is.
> > > I have a 3.6864Mhz crystal on XT1 of a '156 device.
> > >
> > > Code:
> > >
> > > /* XT2 off, LFXT1 Mode = Hi Freq, ACLK / 1 (3.6864 MHz) */
> > > BCSCTL1 = XT2OFF + XTS + DIVA_0;
> > >
> > > /* selm0 + sem1 selects MCLK source as LFXT1CLK (i.e. 3.6864MHz). MCLK divided by 2 */
> > > BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;
> > >
> > > /* USART setup */
> > > UCTL0 = CHAR+SPB; /* 8-bit character, no parity, 2 stop bits */
> > > UTCTL0 |= SSEL0; /* UCLK = ACLK */
> > > UBR00 = 0x80; /* 3.68Mhz/9600 = 383 (low byte) */
> > > UBR10 = 0x01; /* high byte */
> > >
> > > UMCTL0 = 0x00; /* no modulation */
> > > ME1 |= UTXE0 + URXE0; /* Enable USART0 TXD/RXD */
> > > IE1 |= URXIE0; /* Enable USART0 RX interrupt */
> > > P3SEL |= 0x30; /* P3.4,5 = USART0 TXD/RXD */
> > > P3DIR |= 0x10; /* P3.4 output direction */
> > >
> > > Can anyone tell me the above doesn't work at 9600, whereas if I set:
> > >
> > > UBR00 = 0x20;
> > > UBR10 = 0x00; /* high byte */
> > >
> > > This does work at 115200 baud!!?
> > >
> > > Any hints appreciated!
> > >
> > > Thanks
> > >
> > > Regards,
> > > Darren
> > >
> > > ________________________________
> > > This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
> > >
> > > If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > > ________________________________
> > > This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
> > >
> > > If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> ________________________________
> This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
>
> If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> [Non-text portions of this message have been removed]
>
________________________________
This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.

If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
[Non-text portions of this message have been removed]

------------------------------------

______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Out of interest, does anyone have a fairly precise delay routine which is independent of clock?
(If so, I'd appreciate a look at it)

Now I have another problem. Since changing the clock setup, my capture/compare module (counting) result
has changed, yet I've not changed the clock source of the module (ACLK), nor have I changed the
division of ACLK.

Module setup:
/* timer A setup (capture / compare for sensor measurement) */
TACTL = TASSEL_1 + MC_2 + TAIE; /* ACLK, continuous UP, ints enabled */
TAR = 0; /* begin with zero in timer register */
TACCTL1 = CM_1 + CCIS_0 + SCS + CAP + CCIE; /* +ve edge, CC1A, sync capture mode, int enable */
TACCTL2 = CM_1 + CCIS_0 + SCS + CAP + CCIE; /* +ve edge, sync capture mode, CC2A, int enable */

By changing my clock setup from:

BCSCTL2 = SELS; /* Basic clock system control 2 */

To:

BCSCTL2 = SELS + SELM_3 + DIVM_0;

The result has roughly halved, yet I've not changed ACLK in any way.

Any ideas? (preferably without hidden messages or sarcasm) ;-)

Thanks

Darren

From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of Darren Logan
Sent: 01 October 2009 09:58
To: m...@yahoogroups.com
Subject: RE: [msp430] Re: UART baud rate weirdness!

As always, I'm appreciative of the wit and humour which prevails on this list.

You guys... ya just SO funny.

Meanwhile, I've found the problem.

I have a delay() routine which is dependant on the MCLK. This delay is used between switching my
RS485 device to/from input/output.
By changing the clock, I've changed my delays - which in turn "clipped" some of the outgoing data from the MSP.

I've adjusted my delays.

Sorted. :)

From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of old_cow_yellow
Sent: 30 September 2009 23:14
To: m...@yahoogroups.com
Subject: [msp430] Re: UART baud rate weirdness!

I know some teenagers, who can drive at 100 mile/hr "without any problem". But they got all kinds of problems at 35 mile/hr. They ignore stop signs and traffic lights.

--- In m...@yahoogroups.com, Darren Logan wrote:
>
> Hi,
>
> Thanks for pointing out the obvious (setting the other device baud rate) - I'm not that stupid!
> (although arguably I am a little bit stupid)
>
> Sorry - what I mean by work and not work is I'm using modBUS. By not working I mean I get no
> response on my modbus master (PC).
>
> What I don't understand is why does the 115200 baud works, yet 9600 doesn't on the same clock configuration.
>
> The firmware starts with the baud set to 9600, but with this:
> BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;
>
> I get no response, yet with this:
> BCSCTL2 = SELS;
>
> 9600 baud does work.
>
> It seems that the MSP is receiving the correct command at 9600. It's the response from the MSP that
> isn't correct.
>
> Thanks
>
> Darren
>
> From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of old_cow_yellow
> Sent: 30 September 2009 16:17
> To: m...@yahoogroups.com
> Subject: [msp430] Re: UART baud rate weirdness!
>
> There are all kinds of possible problems. It takes much longer time for 9600 to "work". Did you wait for flags?
>
> --- In m...@yahoogroups.com, "Michael" wrote:
> >
> > What do you mean it doesn't work?! What doesn't work?
> > It might not even have anything to do with the UART hardware but with the software that uses the much slower baud rate (timer expiration?).
> > Did you set the slower baudrate on the other device too?
> > Or maybe you haven't disabled the watchdog!
> >
> > Michael K.
> >
> > --- In m...@yahoogroups.com, Darren Logan wrote:
> > >
> > > One more thing:
> > >
> > > If I use the following setup:
> > >
> > > //BCSCTL2 = SELS; /* Basic clock system control 2. THIS WORKED TO BEGIN @ 9600 BAUD */
> > >
> > > Then 9600 baud does work!!
> > >
> > > I get confused over all the clock configurations!!
> > >
> > > Vbr,
> > > Darren
> > >
> > > From: m...@yahoogroups.com [mailto:m...@yahoogroups.com] On Behalf Of Darren Logan
> > > Sent: 30 September 2009 09:46
> > > To: m...@yahoogroups.com
> > > Subject: [msp430] UART baud rate weirdness!
> > > Importance: High
> > >
> > >
> > >
> > > Hi all,
> > >
> > > I'm trying to work out why at 9600 baud my comms isn't working, but at 115200 it is.
> > > I have a 3.6864Mhz crystal on XT1 of a '156 device.
> > >
> > > Code:
> > >
> > > /* XT2 off, LFXT1 Mode = Hi Freq, ACLK / 1 (3.6864 MHz) */
> > > BCSCTL1 = XT2OFF + XTS + DIVA_0;
> > >
> > > /* selm0 + sem1 selects MCLK source as LFXT1CLK (i.e. 3.6864MHz). MCLK divided by 2 */
> > > BCSCTL2 = SELS + SELM0 + SELM1 + DIVM1;
> > >
> > > /* USART setup */
> > > UCTL0 = CHAR+SPB; /* 8-bit character, no parity, 2 stop bits */
> > > UTCTL0 |= SSEL0; /* UCLK = ACLK */
> > > UBR00 = 0x80; /* 3.68Mhz/9600 = 383 (low byte) */
> > > UBR10 = 0x01; /* high byte */
> > >
> > > UMCTL0 = 0x00; /* no modulation */
> > > ME1 |= UTXE0 + URXE0; /* Enable USART0 TXD/RXD */
> > > IE1 |= URXIE0; /* Enable USART0 RX interrupt */
> > > P3SEL |= 0x30; /* P3.4,5 = USART0 TXD/RXD */
> > > P3DIR |= 0x10; /* P3.4 output direction */
> > >
> > > Can anyone tell me the above doesn't work at 9600, whereas if I set:
> > >
> > > UBR00 = 0x20;
> > > UBR10 = 0x00; /* high byte */
> > >
> > > This does work at 115200 baud!!?
> > >
> > > Any hints appreciated!
> > >
> > > Thanks
> > >
> > > Regards,
> > > Darren
> > >
> > > ________________________________
> > > This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
> > >
> > > If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> > >
> > > [Non-text portions of this message have been removed]
> > >
> > >
> > > ________________________________
> > > This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
> > >
> > > If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
> ________________________________
> This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.
>
> If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
> [Non-text portions of this message have been removed]
>

________________________________
This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.

If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.

[Non-text portions of this message have been removed]
________________________________
This communication contains information which is confidential and may also be privileged It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited.

If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
[Non-text portions of this message have been removed]

------------------------------------

______________________________
Have a look at the new TI MCU Center on EmbeddedRelated.com!


(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )