Hi All,
couple days ago I started to work on aplication (based on
MSP430F1121) where I need to implement a UART 9600 baud to
comunication with peripherals.
Idea I get from slaa078a.pdf where describes an implementing a UART
function with TimerA3.
At first I decide to write piece of CODE for transmit only.
I get a file 11x1_uart1.s43 from package slaa078a.zip and remove a
part for receive bytes...
This is it:
;==================================================================#include
"msp430x11x1.h"
; MSP430x11x(1) Demo - 9600-baud UART using 3.579545Hz Crystal
; MSP430F1121
; -----------------
; /|\| XIN|-
; | | | 3.58Mhz
; --|RST XOUT|-
; | |
; | | 9600 8N1
; | TX/P1.1|-------->
; | TX/P2.2|<--------
;
; CPU registers used
#define RXTXData R4
#define BitCnt R5
;
; Conditions for 9600 Baud HW/SW UART, ACLK = 3.579545MHz
Bitime equ 0373 ; 104 us
TXD set 002h ; TXD on P1.1
ORG 0F000h ; Program Start
;---------------------------------
--------
RESET mov.w #300h,SP ; Initialize Stackpointer
StopWDT mov.w #WDTPW+WDTHOLD,&WDTCTL ; Stop WDT
SetupC0 mov.w #OUT,&CCTL0 ; TXD Idle as Mark
SetupTA mov.w #TASSEL0+MC1,&TACTL ; ACLK, continous mode
SetupP1_2 bis.b #TXD,&P1SEL ; P1.1/TA0 for TXD function
bis.b #TXD,&P1DIR ; TXD output on P1
SetupBC bis.b #XTS+RSEL0+RSEL1+RSEL2,&BCSCTL1
; ACLK = LFXT1 HF XTAL, RSEL for high DCO speed
SetupOsc bic.b #OFIFG,&IFG1 ; Clear OSC fault flag
mov.b #0FFh,R15
SetupOsc1 dec.b R15 ; Ddelay to ensure startup
jnz SetupOsc1
bit.b #OFIFG,&IFG1 ; OSC fault flag set?
jnz SetupOsc ;
bis.b #SELM1+SELM0,&BCSCTL2 ; (CPU) MCLK = LFXT1
eint ; General enable interrupts
Mainloop mov.b #055h,RXTXData
call #TX_Byte ; TX Back RXed Byte
Received
jmp Mainloop ;
;--------------------------------
TX_Byte; Subroutine that will TX Byte from RXTXData Buffer
;--------------------------
mov.w #TX_Count,BitCnt ; TX_Count --> Branch Pointer
push.w &TAR ; Current state of TA Counter
add.w #Bitime,0(SP) ; Bitime till next bit
pop.w &CCR0 ; CCR0=Bitime till next bit
mov.w #OUTMOD2+OUTMOD0+CCIE,&CCTL0
; TXD = Space = Start Bit
TX_Wait bit.w #CCIE,&CCTL0 ; Wait for TX completion
jnz TX_Wait
ret ; Return from subroutine
;-------------------------
TA0_ISR; CCR0/UART ISR, RXTXData Buffer holds UART Data
;-------------------------
add.w #Bitime,&CCR0 ; Bitime till next bit
br @BitCnt+ ; Branch To Routine
;
TX_Bit rra.b RXTXData ; LSB is shifted to
carry
jc TX_Mark ; Jump if bit = 1
TX_Space bis.w #OUTMOD2,&CCTL0 ; TX Space
reti ;
TX_Comp bic.w #CCIE,&CCTL0 ;All Bits TX,disable interrupt
TX_Mark bic.w #OUTMOD2,&CCTL0 ; TX Mark
reti
;
TX_Count DW TX_Bit ; TX First Data Bit
DW TX_Bit ;
DW TX_Bit ;
DW TX_Bit ;
DW TX_Bit ;
DW TX_Bit ;
DW TX_Bit ;
DW TX_Bit ;
DW TX_Mark ; TX Stop Bit= Mark
TX_End DW TX_Comp ; TX Complete and
Complete
;-------------------------------
; Interrupt Vectors Used MSP430x11x1
;--------------------------------
ORG 0FFFEh ; MSP430 RESET Vector
DW RESET ;
ORG 0FFF2h ; Timer_A0 Vector
DW TA0_ISR ;
END
;==================================================================
This program work fine, it's always transmit a 055h byte, and on
osciloscope it loks like that:
http://hmm.iglu.sk/~janko/msp430/9600_OK.gif
Until now everythink is fine, but I decide to change speed of MCLK
(TimerA remain to ACLK and 3.5 MHz Xtal).
Because there is only one Xtal, I have only one choice, to drive a
MCLK from DCO which I set to high speed (bis.b
#XTS+RSEL0+RSEL1+RSEL2,&BCSCTL1) and I have to remove this line
of
CODE: (bis.b #SELM1+SELM0,&BCSCTL2).
After compile and RUN the osciloscope show this:
http://hmm.iglu.sk/~janko/msp430/9600_BAD1.gif
http://hmm.iglu.sk/~janko/msp430/9600_BAD2.gif
http://hmm.iglu.sk/~janko/msp430/9600_BAD3.gif
Something happened when interupt routine change a state for OUTPUT
UNIT from SET to RESET or RESET to SET
bis.w #OUTMOD2,&CCTL0 <---> bic.w #OUTMOD2,&CCTL0)
Have anybody an explain for tha think ?
Jano
OUTPUT UNIT IN MSP430F1121
Started by ●June 26, 2003
Reply by ●June 30, 20032003-06-30
Your problem might lie in the use of asynchronous clocks leading to errors in reading TAR. To avoid this read TAR until you are sure that you have a clean read. You can either stop TimerA to do this without changing your existing code or you could read several times until you get 2 reads the same (or maybe 1 digit apart). eg: <stop TimerA> push.w &TAR ; Current state of TA Counter <start TimerA> I quote: "Note: Modifying Timer_A Registers It is recommended to stop the timer before modifying its operation (with exception of the interrupt enable and interrupt flag) to avoid errant operating conditions. When the TACLK is asynchronous to the CPU clock, any read from TAR should occur while the timer is not operating or the results may be unpredictable. Any write to TAR will take effect immediately." Regards, Hugh > Hi All, couple days ago I started to work on aplication (based on MSP430F1121) where I need to implement a UART 9600 baud to comunication with peripherals. Idea I get from slaa078a.pdf where describes an implementing a UART function with TimerA3. At first I decide to write piece of CODE for transmit only. I get a file 11x1_uart1.s43 from package slaa078a.zip and remove a part for receive bytes... This is it: ;==================================================================#include "msp430x11x1.h" ; MSP430x11x(1) Demo - 9600-baud UART using 3.579545Hz Crystal ; MSP430F1121 ; ----------------- ; /|\| XIN|- ; | | | 3.58Mhz ; --|RST XOUT|- ; | | ; | | 9600 8N1 ; | TX/P1.1|--------> ; | TX/P2.2|<-------- ; ; CPU registers used #define RXTXData R4 #define BitCnt R5 ; ; Conditions for 9600 Baud HW/SW UART, ACLK = 3.579545MHz Bitime equ 0373 ; 104 us TXD set 002h ; TXD on P1.1 ORG 0F000h ; Program Start ;--------------------------------- -------- RESET mov.w #300h,SP ; Initialize Stackpointer StopWDT mov.w #WDTPW+WDTHOLD,&WDTCTL ; Stop WDT SetupC0 mov.w #OUT,&CCTL0 ; TXD Idle as Mark SetupTA mov.w #TASSEL0+MC1,&TACTL ; ACLK, continous mode SetupP1_2 bis.b #TXD,&P1SEL ; P1.1/TA0 for TXD function bis.b #TXD,&P1DIR ; TXD output on P1 SetupBC bis.b #XTS+RSEL0+RSEL1+RSEL2,&BCSCTL1 ; ACLK = LFXT1 HF XTAL, RSEL for high DCO speed SetupOsc bic.b #OFIFG,&IFG1 ; Clear OSC fault flag mov.b #0FFh,R15 SetupOsc1 dec.b R15 ; Ddelay to ensure startup jnz SetupOsc1 bit.b #OFIFG,&IFG1 ; OSC fault flag set? jnz SetupOsc ; bis.b #SELM1+SELM0,&BCSCTL2 ; (CPU) MCLK = LFXT1 eint ; General enable interrupts Mainloop mov.b #055h,RXTXData call #TX_Byte ; TX Back RXed Byte Received jmp Mainloop ; ;-------------------------------- TX_Byte; Subroutine that will TX Byte from RXTXData Buffer ;-------------------------- mov.w #TX_Count,BitCnt ; TX_Count --> Branch Pointer push.w &TAR ; Current state of TA Counter add.w #Bitime,0(SP) ; Bitime till next bit pop.w &CCR0 ; CCR0=Bitime till next bit mov.w #OUTMOD2+OUTMOD0+CCIE,&CCTL0 ; TXD = Space = Start Bit TX_Wait bit.w #CCIE,&CCTL0 ; Wait for TX completion jnz TX_Wait ret ; Return from subroutine ;------------------------- TA0_ISR; CCR0/UART ISR, RXTXData Buffer holds UART Data ;------------------------- add.w #Bitime,&CCR0 ; Bitime till next bit br @BitCnt+ ; Branch To Routine ; TX_Bit rra.b RXTXData ; LSB is shifted to carry jc TX_Mark ; Jump if bit = 1 TX_Space bis.w #OUTMOD2,&CCTL0 ; TX Space reti ; TX_Comp bic.w #CCIE,&CCTL0 ;All Bits TX,disable interrupt TX_Mark bic.w #OUTMOD2,&CCTL0 ; TX Mark reti ; TX_Count DW TX_Bit ; TX First Data Bit DW TX_Bit ; DW TX_Bit ; DW TX_Bit ; DW TX_Bit ; DW TX_Bit ; DW TX_Bit ; DW TX_Bit ; DW TX_Mark ; TX Stop Bit= Mark TX_End DW TX_Comp ; TX Complete and Complete ;------------------------------- ; Interrupt Vectors Used MSP430x11x1 ;-------------------------------- ORG 0FFFEh ; MSP430 RESET Vector DW RESET ; ORG 0FFF2h ; Timer_A0 Vector DW TA0_ISR ; END ;================================================================== This program work fine, it's always transmit a 055h byte, and on osciloscope it loks like that: http://hmm.iglu.sk/~janko/msp430/9600_OK.gif Until now everythink is fine, but I decide to change speed of MCLK (TimerA remain to ACLK and 3.5 MHz Xtal). Because there is only one Xtal, I have only one choice, to drive a MCLK from DCO which I set to high speed (bis.b #XTS+RSEL0+RSEL1+RSEL2,&BCSCTL1) and I have to remove this line of CODE: (bis.b #SELM1+SELM0,&BCSCTL2). After compile and RUN the osciloscope show this: http://hmm.iglu.sk/~janko/msp430/9600_BAD1.gif http://hmm.iglu.sk/~janko/msp430/9600_BAD2.gif http://hmm.iglu.sk/~janko/msp430/9600_BAD3.gif Something happened when interupt routine change a state for OUTPUT UNIT from SET to RESET or RESET to SET bis.w #OUTMOD2,&CCTL0 <---> bic.w #OUTMOD2,&CCTL0) Have anybody an explain for tha think ? Jano __________________________________
Reply by ●July 1, 20032003-07-01
Hi,
You suggestion solve problem only with potential error on the start
of the UART transmit:
;---------------------
TX_Byte; Subroutine that will TX Byte from RXTXData Buffer
;------------------------
mov.w #TX_Count,BitCnt ; TX_Count --> Branch Pointer
push.w &TAR ; Current state of TA Counter
add.w #Bitime,0(SP) ; Bitime till next bit
pop.w &CCR0 ; CCR0=Bitime till next bit
;------------------------
Next in the transmit routine software does not read from the TAR.
Software only change the value of the CCR0...
;--------------------
TA0_ISR; CCR0/UART ISR, RXTXData Buffer holds UART Data
;--------------------
add.w #Bitime,&CCR0 ; Bitime till next bit
br @BitCnt+ ; Branch To Routine
TX_Bit rra.b RXTXData ; LSB is shifted to carry
jc TX_Mark ; Jump if bit = 1
TX_Space bis.w #OUTMOD2,&CCTL0 ; TX Space
reti ;
TX_Comp bic.w #CCIE,&CCTL0 ; All Bits RX, disable interrupt
TX_Mark bic.w #OUTMOD2,&CCTL0 ; TX Mark
reti
"slau049c.pdf page 219"
"Set"
The output is set when the timer counts to the TACCRx value. It
remains set until a reset of the timer, or until another
output mode is selected and affects the output.
"Reset"
The output is reset when the timer counts to the TACCRx value. It
remains reset until another output mode is selected and
affects the output.
;--------------------
...and hardware compare CCRO with TAR and then change the OUTPUT...
This is strange, because that ERROR
http://hmm.iglu.sk/~janko/msp430/9600_BAD1.gif
appears only occasionally.
I know that happens because TimerA and MCLK source from different
clock, but why ?
Jano
--- In msp430@msp4..., Hugh Molesworth <nzbackpackers@y...>
wrote:
> Your problem might lie in the use of asynchronous clocks leading to
errors in
> reading TAR. To avoid this read TAR until you are
sure that you
have a clean
> read. You can either stop TimerA to do this
without changing your
existing code
> or you could read several times until you get 2
reads the same (or
maybe 1
> digit apart).
>
> eg:
> <stop TimerA>
> push.w &TAR ; Current state of TA Counter
> <start TimerA>
>
> I quote:
>
> "Note: Modifying Timer_A Registers
> It is recommended to stop the timer before modifying its operation
(with
> exception of the interrupt enable and interrupt
flag) to avoid
errant operating
> conditions.
> When the TACLK is asynchronous to the CPU clock, any read from TAR
> should occur while the timer is not operating or the results may be
> unpredictable. Any write to TAR will take effect immediately."
>
> Regards, Hugh
Reply by ●July 1, 20032003-07-01
Good point. There are two other things I can see: 1/ turn off the XT2 oscillator by setting XT2OFF in BCSCTL1 (even though the 1121 has no XT2) 2/ You have selected DCO as the baud clock source and LFXT1 as the Mclk source. Didn't you want them the other way around? ie: bis.b #SELM1+SELM0,&BCSCTL2 ; wrong, cpu = LFXT1, TimerA = DCOCLK should be: bis.b #SELS,&BCSCTL2 ; right, cpu = DCOCLK, TimerA = LFXT1 Hope this helps, I can't think of anything else. Regards, Hugh >Hi, You suggestion solve problem only with potential error on the start of the UART transmit: ;--------------------- TX_Byte; Subroutine that will TX Byte from RXTXData Buffer ;------------------------ mov.w #TX_Count,BitCnt ; TX_Count --> Branch Pointer push.w &TAR ; Current state of TA Counter add.w #Bitime,0(SP) ; Bitime till next bit pop.w &CCR0 ; CCR0=Bitime till next bit ;------------------------ Next in the transmit routine software does not read from the TAR. Software only change the value of the CCR0... ;-------------------- TA0_ISR; CCR0/UART ISR, RXTXData Buffer holds UART Data ;-------------------- add.w #Bitime,&CCR0 ; Bitime till next bit br @BitCnt+ ; Branch To Routine TX_Bit rra.b RXTXData ; LSB is shifted to carry jc TX_Mark ; Jump if bit = 1 TX_Space bis.w #OUTMOD2,&CCTL0 ; TX Space reti ; TX_Comp bic.w #CCIE,&CCTL0 ; All Bits RX, disable interrupt TX_Mark bic.w #OUTMOD2,&CCTL0 ; TX Mark reti "slau049c.pdf page 219" "Set" The output is set when the timer counts to the TACCRx value. It remains set until a reset of the timer, or until another output mode is selected and affects the output. "Reset" The output is reset when the timer counts to the TACCRx value. It remains reset until another output mode is selected and affects the output. ;-------------------- ...and hardware compare CCRO with TAR and then change the OUTPUT... This is strange, because that ERROR http://hmm.iglu.sk/~janko/msp430/9600_BAD1.gif appears only occasionally. I know that happens because TimerA and MCLK source from different clock, but why ? Jano __________________________________
Reply by ●July 2, 20032003-07-02
--- In msp430@msp4..., Hugh Molesworth <nzbackpackers@y...> wrote: > Good point. > > There are two other things I can see: > > 1/ turn off the XT2 oscillator by setting XT2OFF in BCSCTL1 (even though the 1121 has no XT2) > It does not help. > 2/ You have selected DCO as the baud clock source and LFXT1 as the > Mclk source. Didn't you want them the other way around? > > ie: > bis.b #SELM1+SELM0,&BCSCTL2 ; wrong, cpu = LFXT1, TimerA = DCOCLK > > should be: > bis.b #SELS,&BCSCTL2 ; right, cpu = DCOCLK, TimerA = LFXT1 TimerA I source from ACLK not from SMCLK. Let me explain again. In the original file 11x1_uart1.s43 from package slaa078a.zip was that configuration: LFXT1 -> ACLK -> TimerA (mov.w #TASSEL0+MC1,&TACTL ;ACLK, continous mode LFXT1 -> MCLK (bis.b #SELM1+SELM0,&BCSCTL2 ;(CPU) MCLK = LFXT1 This works fine: http://hmm.iglu.sk/~janko/msp430/9600_OK.gif But if I switch to this: LFXT1 -> ACLK -> TimerA (3.5MHz) DCO -> MCLK (~5MHz) or evene this: DCO -> SMCLK -> TimerA (~5MHz) LFXT1 -> MCLK (3.5 MHz) occasionally happens this ERRORs: http://hmm.iglu.sk/~janko/msp430/9600_BAD1.gif I'm not beginner, there is no posibble software errors. I have a suspicion that Texas Instruments have a hidden BUG in their product(s)! Jano
Reply by ●July 4, 20032003-07-04
Maybe it's due to thrashing the register. The TI notes are fine for
getting
started with, but are of little use in real applications. It's unusual to
sit
in a loop continuously reading a register (thrashing) when it's not
necessary.
On some devices internal bus contentions lead to occasional spurious errors
when doing this.
Try going into LPM3 while waiting for the Tx routine to complete so that you
don't have to sit in a loop continuously reading a register. The Tx routine
wakes up from LPM3 when the transmission is complete. If you do this you can
prove whether or not there is such a problem with TI's MSP430 hardware.
I'd be
interested to hear if this is the case (as I expect would TI).
Example using your code:
Change:
TX_Wait bit.w #CCIE,&CCTL0 ; Wait for TX completion
jnz TX_Wait
ret ; Return from subroutine
To:
TX_Wait:
bis.w #LPM3,SR ; Enter LPM3, wait for wakeup
ret
===
Change:
TX_Comp bic.w #CCIE,&CCTL0 ;All Bits TX,disable interrupt
TX_Mark bic.w #OUTMOD2,&CCTL0 ; TX Mark
reti
To:
TX_Comp bic.w #CCIE,&CCTL0 ;All Bits TX,disable interrupt
bic.w #LPM3,0(SP) ; Wakeup main after reti
TX_Mark bic.w #OUTMOD2,&CCTL0 ; TX Mark
reti
You might want to check the LPM3 coding above; I always do this in C with
macros, but I think this is the equivalent assembler.
Regards, Hugh
> Good point.
>
> There are two other things I can see:
>
> 1/ turn off the XT2 oscillator by setting XT2OFF in BCSCTL1 (even
though the 1121 has no XT2)
>
It does not help.
> 2/ You have selected DCO as the baud clock source
and LFXT1 as the
> Mclk source. Didn't you want them the other way around?
>
> ie:
> bis.b #SELM1+SELM0,&BCSCTL2 ; wrong, cpu = LFXT1, TimerA = DCOCLK
>
> should be:
> bis.b #SELS,&BCSCTL2 ; right, cpu = DCOCLK, TimerA = LFXT1
TimerA I source from ACLK not from SMCLK.
Let me explain again.
In the original file 11x1_uart1.s43 from package slaa078a.zip was
that configuration:
LFXT1 -> ACLK -> TimerA (mov.w #TASSEL0+MC1,&TACTL ;ACLK,
continous
mode
LFXT1 -> MCLK (bis.b #SELM1+SELM0,&BCSCTL2 ;(CPU) MCLK = LFXT1
This works fine: http://hmm.iglu.sk/~janko/msp430/9600_OK.gif
But if I switch to this:
LFXT1 -> ACLK -> TimerA (3.5MHz)
DCO -> MCLK (~5MHz)
or evene this:
DCO -> SMCLK -> TimerA (~5MHz)
LFXT1 -> MCLK (3.5 MHz)
occasionally happens this ERRORs:
http://hmm.iglu.sk/~janko/msp430/9600_BAD1.gif
I'm not beginner, there is no posibble software errors.
I have a suspicion that Texas Instruments have a hidden BUG in their
product(s)!
Jano
__________________________________
Reply by ●July 4, 20032003-07-04
Do you checked msp430 ERATA section at TI website? I think there are some problems with 11x1 in this case (changing out mode of Timer_A eventually?). If TACLK is asynchronous to MCLK there could be also an erata in some cases. Please check erata of all 11x1 devices. Cannot reach ERATA section at TI website at the moment (possibly down?). At page 11-4 of slau049c.pdf a note about modifying Timer_A registers says it is recommended to stop the timer before modifying its operation (except interrupt flags). Regards, Claus Hugh Molesworth wrote: > Maybe it's due to thrashing the register. The TI notes are fine for getting > started with, but are of little use in real applications. It's unusual to sit > in a loop continuously reading a register (thrashing) when it's not necessary. > On some devices internal bus contentions lead to occasional spurious errors > when doing this. > > Try going into LPM3 while waiting for the Tx routine to complete so that you > don't have to sit in a loop continuously reading a register. The Tx routine > wakes up from LPM3 when the transmission is complete. If you do this you can > prove whether or not there is such a problem with TI's MSP430 hardware. I'd be > interested to hear if this is the case (as I expect would TI). > > Example using your code: > > Change: > TX_Wait bit.w #CCIE,&CCTL0 ; Wait for TX completion > jnz TX_Wait > ret ; Return from subroutine > To: > TX_Wait: > bis.w #LPM3,SR ; Enter LPM3, wait for wakeup > ret > ===> > Change: > TX_Comp bic.w #CCIE,&CCTL0 ;All Bits TX,disable interrupt > TX_Mark bic.w #OUTMOD2,&CCTL0 ; TX Mark > reti > > To: > TX_Comp bic.w #CCIE,&CCTL0 ;All Bits TX,disable interrupt > bic.w #LPM3,0(SP) ; Wakeup main after reti > TX_Mark bic.w #OUTMOD2,&CCTL0 ; TX Mark > reti > > You might want to check the LPM3 coding above; I always do this in C with > macros, but I think this is the equivalent assembler. > > Regards, Hugh > > >>Good point. >> >>There are two other things I can see: >> >>1/ turn off the XT2 oscillator by setting XT2OFF in BCSCTL1 (even > > though the 1121 has no XT2) > > > It does not help. > > > >>2/ You have selected DCO as the baud clock source and LFXT1 as the >>Mclk source. Didn't you want them the other way around? >> >>ie: >>bis.b #SELM1+SELM0,&BCSCTL2 ; wrong, cpu = LFXT1, TimerA = DCOCLK >> >>should be: >>bis.b #SELS,&BCSCTL2 ; right, cpu = DCOCLK, TimerA = LFXT1 > > > TimerA I source from ACLK not from SMCLK. > > > Let me explain again. > > In the original file 11x1_uart1.s43 from package slaa078a.zip was > that configuration: > > LFXT1 -> ACLK -> TimerA (mov.w #TASSEL0+MC1,&TACTL ;ACLK, continous > mode > LFXT1 -> MCLK (bis.b #SELM1+SELM0,&BCSCTL2 ;(CPU) MCLK = LFXT1 > > This works fine: http://hmm.iglu.sk/~janko/msp430/9600_OK.gif > > But if I switch to this: > > LFXT1 -> ACLK -> TimerA (3.5MHz) > DCO -> MCLK (~5MHz) > > or evene this: > > DCO -> SMCLK -> TimerA (~5MHz) > LFXT1 -> MCLK (3.5 MHz) > > occasionally happens this ERRORs: > http://hmm.iglu.sk/~janko/msp430/9600_BAD1.gif > > I'm not beginner, there is no posibble software errors. > I have a suspicion that Texas Instruments have a hidden BUG in their > product(s)! > > Jano > > > __________________________________ > > > > . > > > > ">http://docs.yahoo.com/info/terms/ > > > -- -------------------------------- sevenstax GmbH Hamburger Allee 43 30161 Hannover - Germany Claus Krause Development mailto:claus.krause@clau... http://www.sevenstax.de Personal: +49 511 213 592 52 Company: +49 511 473 860 4 Fax: +49 721 151 505 622 --------------------------------
Reply by ●July 4, 20032003-07-04
Should you not be checking the CCIFG bit rather than the CCIE bit? I
don't know the rest of it but its unusual to do it this way.
Al
Hugh Molesworth wrote:
> Maybe it's due to thrashing the register. The TI notes are fine for
getting
> started with, but are of little use in real applications. It's unusual
to sit
> in a loop continuously reading a register (thrashing) when it's not
necessary.
> On some devices internal bus contentions lead to occasional spurious errors
> when doing this.
>
> Try going into LPM3 while waiting for the Tx routine to complete so that
you
> don't have to sit in a loop continuously reading a register. The Tx
routine
> wakes up from LPM3 when the transmission is complete. If you do this you
can
> prove whether or not there is such a problem with TI's MSP430
hardware. I'd be
> interested to hear if this is the case (as I expect would TI).
>
> Example using your code:
>
> Change:
> TX_Wait bit.w #CCIE,&CCTL0 ; Wait for TX completion
> jnz TX_Wait
> ret ; Return from subroutine
> To:
> TX_Wait:
> bis.w #LPM3,SR ; Enter LPM3, wait for wakeup
> ret
> ===>
> Change:
> TX_Comp bic.w #CCIE,&CCTL0 ;All Bits TX,disable interrupt
> TX_Mark bic.w #OUTMOD2,&CCTL0 ; TX Mark
> reti
>
> To:
> TX_Comp bic.w #CCIE,&CCTL0 ;All Bits TX,disable interrupt
> bic.w #LPM3,0(SP) ; Wakeup main after reti
> TX_Mark bic.w #OUTMOD2,&CCTL0 ; TX Mark
> reti
>
> You might want to check the LPM3 coding above; I always do this in C with
> macros, but I think this is the equivalent assembler.
>
> Regards, Hugh
>
>
>>Good point.
>>
>>There are two other things I can see:
>>
>>1/ turn off the XT2 oscillator by setting XT2OFF in BCSCTL1 (even
>
> though the 1121 has no XT2)
>
>
> It does not help.
>
>
>
>>2/ You have selected DCO as the baud clock source and LFXT1 as the
>>Mclk source. Didn't you want them the other way around?
>>
>>ie:
>>bis.b #SELM1+SELM0,&BCSCTL2 ; wrong, cpu = LFXT1, TimerA =
DCOCLK
>>
>>should be:
>>bis.b #SELS,&BCSCTL2 ; right, cpu = DCOCLK, TimerA = LFXT1
>
>
> TimerA I source from ACLK not from SMCLK.
>
>
> Let me explain again.
>
> In the original file 11x1_uart1.s43 from package slaa078a.zip was
> that configuration:
>
> LFXT1 -> ACLK -> TimerA (mov.w #TASSEL0+MC1,&TACTL
;ACLK, continous
> mode
> LFXT1 -> MCLK (bis.b #SELM1+SELM0,&BCSCTL2 ;(CPU) MCLK = LFXT1
>
> This works fine: http://hmm.iglu.sk/~janko/msp430/9600_OK.gif
>
> But if I switch to this:
>
> LFXT1 -> ACLK -> TimerA (3.5MHz)
> DCO -> MCLK (~5MHz)
>
> or evene this:
>
> DCO -> SMCLK -> TimerA (~5MHz)
> LFXT1 -> MCLK (3.5 MHz)
>
> occasionally happens this ERRORs:
> http://hmm.iglu.sk/~janko/msp430/9600_BAD1.gif
>
> I'm not beginner, there is no posibble software errors.
> I have a suspicion that Texas Instruments have a hidden BUG in their
> product(s)!
>
> Jano
>
>
> __________________________________
>
>
>
> .
>
>
>
> ">http://docs.yahoo.com/info/terms/
>
>
>
Reply by ●July 4, 20032003-07-04
No, he's doing it right. You need to look at the original post to see
why. It's
a software uart using timer A interrupt and he just wants to know when the
various timer A interupts have all finished. CCIFG will be set and cleared 10
times or so before this happens.
It's an interesting problem though, and looks like it's caused by the
asynchronous clocks. I've used the software uart/Timer A technique a lot
without any problems. In C though :-)
Regards, Hugh
>Should you not be checking the CCIFG bit rather
than the CCIE bit? I
don't know the rest of it but its unusual to do it this way.
Al
__________________________________
Reply by ●July 7, 20032003-07-07
--- In msp430@msp4..., Claus Krause <claus.krause@s...> wrote: > Do you checked msp430 ERATA section at TI website? I think there > are some problems with 11x1 in this case (changing out mode of > Timer_A eventually?). If TACLK is asynchronous to MCLK there could > be also an erata in some cases. Please check erata of all 11x1 > devices. Cannot reach ERATA section at TI website at the moment > (possibly down?). It's good idea, but today 07.07.2003 08:30 CET ERRATA section of TI MSP430 does not response. > At page 11-4 of slau049c.pdf a note about modifying Timer_A > registers says it is recommended to stop the timer before modifying > its operation (except interrupt flags). > > > Regards, > Claus O.K. at that page is this: "When the TACLK is asynchronous to the CPU clock, any read from TAR should occur while the timer is not operating or the results may be unpredictable. Any write to TAR will take effect immediately." This note is understandable, if I want to read TAR and have asynchronous clock for TimerA and MCLK, it's quite good to stop TimerA before reading TAR. But poit is in that TAR is access by hardware (OUTPUT UNIT) not by software?!? --- In msp430@msp4..., Hugh Molesworth <nzbackpackers@y...> wrote: > Maybe it's due to thrashing the register. The TI notes are fine for > getting started with, but are of little use in real applications. > It's unusual to sit in a loop continuously reading a register > (thrashing) when it's not necessary. > On some devices internal bus contentions lead to occasional > spurious errors when doing this. > > Try going into LPM3 while waiting for the Tx routine to complete so > that you don't have to sit in a loop continuously reading a > register. The Tx routine wakes up from LPM3 when the transmission > is complete. If you do this you can prove whether or not there is > such a problem with TI's MSP430 hardware. I'd be > interested to hear if this is the case (as I expect would TI). > > Regards, Hugh > When I implement LPM3, it is work fine, even if TimerA and MCLK asynchronous !!! But at beginning I decide to source MCLK from DCO (~5MHz) and TimerA from ACLK (3.5MHZ), because I need more processor "power" for another tasks which will be run together with UART function. And LPM3 does not help me with that. Result: for safety UART transmit it's necessary to drive TimerA and MCLK from the same source and use XTAL with highest frequencies if more processor "power" needed. Regards, Jano
