On Wed, 18 May 2011 06:53:07 +0000 (UTC), you wrote:
>Jon Kirwan :
>
>> On Tue, 17 May 2011 14:08:16 +0000 (UTC), you wrote:
>>
>>>I remember that there are some silicon bugs (e.g. TA12 TA16) in MSP430
>>>devices related to ACLK and Timer capture/compare after initialization.
>>>
>>>Have you checked the errata of your device?
>>
>> Oh, yes. In fact, I not only mentioned the fact that I had
>> checked the errata in the very post you are replying to, but
>> I also mentioned that fact in the original post, as well. I
>> looked closely at them and am following those rules. I also
>> searched for ACLK in them and checked anything mentioning it.
>
>Sorry, life is short, I just did not really read your very long article, just
>fly over it. Keep it as short as possible and simple. :-)
No harm done.
Jon
G2xx devices without FLL, using DCO, ACLK, and TimerA for software FLL
Started by ●May 16, 2011
Reply by ●May 18, 20112011-05-18
Reply by ●May 18, 20112011-05-18
Jon,
You said:
> .................................. Problem is, I want it
> nailed down hard. Without the theory behind it, no matter
> what I do and no matter how perfectly all my testing verifies
> that it does work, the code generated from my ignorance
> remains a potential risk. I don't like that feeling.
Same here. But I do not think this kind of attitude is a "Problem";) I am just as curious as you are to get to the bottom of what you found.
The reason I included a long long delay is that I know the watch crystal controlled oscillator takes a long long time to start and stabilize. If the device is already powered up for a while (as in the case of a debug session under the control of a development tool), it is not needed. I think it is not related to the bad delta between the first two captures.
Instead, I think changing DIVA from 1 to 8 may have something to do with what you found. As a result, ACLK will change from 32.768 kHz to 4.096 kHz. But when? Will TimerA see the change over? (That is, see one cycle of 32.768 kHz before the 4.096 kHz clocks.)
-- OCY
You said:
> .................................. Problem is, I want it
> nailed down hard. Without the theory behind it, no matter
> what I do and no matter how perfectly all my testing verifies
> that it does work, the code generated from my ignorance
> remains a potential risk. I don't like that feeling.
Same here. But I do not think this kind of attitude is a "Problem";) I am just as curious as you are to get to the bottom of what you found.
The reason I included a long long delay is that I know the watch crystal controlled oscillator takes a long long time to start and stabilize. If the device is already powered up for a while (as in the case of a debug session under the control of a development tool), it is not needed. I think it is not related to the bad delta between the first two captures.
Instead, I think changing DIVA from 1 to 8 may have something to do with what you found. As a result, ACLK will change from 32.768 kHz to 4.096 kHz. But when? Will TimerA see the change over? (That is, see one cycle of 32.768 kHz before the 4.096 kHz clocks.)
-- OCY
Reply by ●May 18, 20112011-05-18
On Wed, 18 May 2011 17:11:25 -0000, OCY wrote:
>Jon,
>
>You said:
>> .................................. Problem is, I want it
>> nailed down hard. Without the theory behind it, no matter
>> what I do and no matter how perfectly all my testing verifies
>> that it does work, the code generated from my ignorance
>> remains a potential risk. I don't like that feeling.
>
> Same here. But I do not think this kind of attitude is a
> "Problem";) I am just as curious as you are to get to the
> bottom of what you found.
I try to imagine defending my code and having to say, "well,
I have some guesses but I really don't know why except that
the delay seems to work."
> The reason I included a long long delay is that I know the
> watch crystal controlled oscillator takes a long long time
> to start and stabilize. If the device is already powered up
> for a while (as in the case of a debug session under the
> control of a development tool), it is not needed. I think it
> is not related to the bad delta between the first two
> captures.
Understood. The code reference I mentioned in the Family
Guide uses a much smaller delay (255) for the same purpose.
Any particular reason you chose NOT to follow their example
here and instead use a delay hundreds of times longer?
Indeed, another question comes to mind. There is a signal
called LFXT1OF that is accessible. It is combinatorial and
doesn't require clearing (nor can it be) and informs on the
status of the LFXT1 crystal. Why not simply wait on that?
Why repeatedly clear, then delay, then test the OFIFG?
> Instead, I think changing DIVA from 1 to 8 may have
> something to do with what you found. As a result, ACLK will
> change from 32.768 kHz to 4.096 kHz. But when? Will TimerA
> see the change over? (That is, see one cycle of 32.768 kHz
> before the 4.096 kHz clocks.)
Hmm. Now that's a thought. Thanks. I'll think about it a
little to see if that holds good water.
Thanks for the sincere discussion OCY. Very nice and
appreciated.
Jon
>Jon,
>
>You said:
>> .................................. Problem is, I want it
>> nailed down hard. Without the theory behind it, no matter
>> what I do and no matter how perfectly all my testing verifies
>> that it does work, the code generated from my ignorance
>> remains a potential risk. I don't like that feeling.
>
> Same here. But I do not think this kind of attitude is a
> "Problem";) I am just as curious as you are to get to the
> bottom of what you found.
I try to imagine defending my code and having to say, "well,
I have some guesses but I really don't know why except that
the delay seems to work."
> The reason I included a long long delay is that I know the
> watch crystal controlled oscillator takes a long long time
> to start and stabilize. If the device is already powered up
> for a while (as in the case of a debug session under the
> control of a development tool), it is not needed. I think it
> is not related to the bad delta between the first two
> captures.
Understood. The code reference I mentioned in the Family
Guide uses a much smaller delay (255) for the same purpose.
Any particular reason you chose NOT to follow their example
here and instead use a delay hundreds of times longer?
Indeed, another question comes to mind. There is a signal
called LFXT1OF that is accessible. It is combinatorial and
doesn't require clearing (nor can it be) and informs on the
status of the LFXT1 crystal. Why not simply wait on that?
Why repeatedly clear, then delay, then test the OFIFG?
> Instead, I think changing DIVA from 1 to 8 may have
> something to do with what you found. As a result, ACLK will
> change from 32.768 kHz to 4.096 kHz. But when? Will TimerA
> see the change over? (That is, see one cycle of 32.768 kHz
> before the 4.096 kHz clocks.)
Hmm. Now that's a thought. Thanks. I'll think about it a
little to see if that holds good water.
Thanks for the sincere discussion OCY. Very nice and
appreciated.
Jon
Reply by ●May 18, 20112011-05-18
On Tue, 17 May 2011 18:41:45 -0000, you wrote:
>Okay, I assume that you did the following:
>
>main: MOV.W #0x280,SP
> MOV.W #WDTPW+WDTHOLD,&WDTCTL
> MOV.B #XCAP_3,&BCSCTL3
> MOV.W #0,R15
>L1: BIC.B #OFIFG,&IFG1
>L2: SUB.W #1,R15
> JNZ L2
> BIT.B #OFIFG,&IFG1
> JNZ L1
> MOV.B #XT2OFF+15,&BCSCTL1
OCY, something else comes to mind about your initialization
code shown above. I hope you don't mind me bringing you back
to this for a moment.
You set up the Microcrystal to XCAP_3 loading. In the header
file, just for anyone who doesn't already have it in mind,
that is:
#define XCAP_3 (0x0C) /* XIN/XOUT Cap : 12.5 pF */
Which is the highest loading. Excessively high loading
results in more power consumption, if I recall correctly and
may slightly pull down the oscillation frequency.
There is a file provided by Microcrystal, available on
e2e.ti.com that covers this crystal and the Launchpad system
from TI. It is at:
http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/166/2772.TI_5F00_MSP430_5F00_Crystal-Recommendations.pdf
If you skip down to page 4 (of 5), it is about the x2xx
family and recommends using XCAP_2, not XCAP_3. As an
alternative, they suggest XCAP_1. Both XCAP_0 and XCAP_3 are
not recommended.
Were you aware?
Jon
>Okay, I assume that you did the following:
>
>main: MOV.W #0x280,SP
> MOV.W #WDTPW+WDTHOLD,&WDTCTL
> MOV.B #XCAP_3,&BCSCTL3
> MOV.W #0,R15
>L1: BIC.B #OFIFG,&IFG1
>L2: SUB.W #1,R15
> JNZ L2
> BIT.B #OFIFG,&IFG1
> JNZ L1
> MOV.B #XT2OFF+15,&BCSCTL1
OCY, something else comes to mind about your initialization
code shown above. I hope you don't mind me bringing you back
to this for a moment.
You set up the Microcrystal to XCAP_3 loading. In the header
file, just for anyone who doesn't already have it in mind,
that is:
#define XCAP_3 (0x0C) /* XIN/XOUT Cap : 12.5 pF */
Which is the highest loading. Excessively high loading
results in more power consumption, if I recall correctly and
may slightly pull down the oscillation frequency.
There is a file provided by Microcrystal, available on
e2e.ti.com that covers this crystal and the Launchpad system
from TI. It is at:
http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/166/2772.TI_5F00_MSP430_5F00_Crystal-Recommendations.pdf
If you skip down to page 4 (of 5), it is about the x2xx
family and recommends using XCAP_2, not XCAP_3. As an
alternative, they suggest XCAP_1. Both XCAP_0 and XCAP_3 are
not recommended.
Were you aware?
Jon
Reply by ●May 19, 20112011-05-19
Jon,
Thanks. I was not aware of the proper load cap of that crystal.
The delay between clearing OFIFG and testing it again, TI examples show a loop of 255. I think that is way too short if you start the code immediately after power up.
I did some test (code is shown below). In order to simulate power up in a debug session (where the target chip is always powered up), I disabled the LFXT1 oscillator, turn on the green LED, and wait for SW2 to be pressed. After that, I turn off the green LED, enabled the oscillator and proceed. Next I capture 4000 deltas and keep the max and min. And then I capture the sum of 16 more deltas. When all finished, I light up the red LED and loop forever.
You may use the debugger to reset the target and start to run. After you see the green LED, wait for various amount of time and press the SW2 button. The green LED will go off and the red LED will come on. At that time, use debugger to stop the CPU and examine the registers to see the max, min, and 16*delta.
My code is shown below. Note that it defines DLT as 255, the value TI uses. I think it is acceptable only if you pressed SW2 immediately after the green LED is on. If you want the delta to be decent enough after the chip was turned off for more than a few seconds, you need to change DLY to a much much bigger number.
BR
OCY
;=============================================================#include
#define DLY 255
ORG 0FFFEh
DC16 main
RSEG CODE
main: MOV.W #0x280,SP
MOV.W #WDTPW+WDTHOLD,&WDTCTL
MOV.B #BIT6,&P1OUT
MOV.B #BIT0+BIT6,&P1DIR
MOV.B #0,&P2SEL
L0: BIT.B #BIT3,&P1IN
JNZ L0 ;green LED is on, wait a while
; and press S2 to continue
MOV.B #0,&P1OUT
MOV.B #XCAP_2,&BCSCTL3
MOV.B #0xC0,&P2SEL
L1: BIC.B #OFIFG,&IFG1
MOV.W DLY,R15
L2: SUB.W #1,R15
JNZ L2
BIT.B #OFIFG,&IFG1
JNZ L1
MOV.B #XT2OFF+15,&BCSCTL1
MOV.W #4000-1,R4 ;count down from 4000
MOV.W #0,R5 ;max delta
MOV.W #0xFFFF,R6 ;min delta
MOV.W #CM_1+CCIS_1+SCS+CAP+OUTMOD_0,&TACCTL0
MOV.W #MC_2+ID_0+TASSEL_2,&TACTL
CALL #await_aclk
L3: MOV.W R15,R14 ;previous
CALL #await_aclk
MOV.W R15,R7
SUB.W R14,R7 ;delta
CMP.W R7,R5
JHS L4
MOV.W R7,R5 ;new max
L4: CMP.W R6,R7
JHS L5
MOV.W R7,R6 ;new min
L5: SUB.W #1,R4 ;repeat?
JNZ L3
MOV.W #16-1,R4 ;count down from 16
L6: CALL #await_aclk
SUB.W #1,R4 ;repeat?
JNZ L6
MOV.W R15,R7
SUB.W R14,R7 ;16*deltas
MOV.B #BIT0,&P1OUT
JMP $ ;red LED is on
; break here and view registers
; R5 = max of 4000 deltas
; R6 = min of 4000 deltas
; R7 = sum of next 16 (0x10) deltas
await_aclk:
await_aclk_01:
bit #CCIFG, &TACCTL0
jeq await_aclk_01
mov &TACCR0, r15
bic #CCIFG, &TACCTL0
ret
END
;=============================================================
--- In m..., Jon Kirwan wrote:
>
> On Tue, 17 May 2011 18:41:45 -0000, you wrote:
>
> >Okay, I assume that you did the following:
> >
> >main: MOV.W #0x280,SP
> > MOV.W #WDTPW+WDTHOLD,&WDTCTL
> > MOV.B #XCAP_3,&BCSCTL3
> > MOV.W #0,R15
> >L1: BIC.B #OFIFG,&IFG1
> >L2: SUB.W #1,R15
> > JNZ L2
> > BIT.B #OFIFG,&IFG1
> > JNZ L1
> > MOV.B #XT2OFF+15,&BCSCTL1
>
> OCY, something else comes to mind about your initialization
> code shown above. I hope you don't mind me bringing you back
> to this for a moment.
>
> You set up the Microcrystal to XCAP_3 loading. In the header
> file, just for anyone who doesn't already have it in mind,
> that is:
>
> #define XCAP_3 (0x0C) /* XIN/XOUT Cap : 12.5 pF */
>
> Which is the highest loading. Excessively high loading
> results in more power consumption, if I recall correctly and
> may slightly pull down the oscillation frequency.
>
> There is a file provided by Microcrystal, available on
> e2e.ti.com that covers this crystal and the Launchpad system
> from TI. It is at:
>
> http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/166/2772.TI_5F00_MSP430_5F00_Crystal-Recommendations.pdf
>
> If you skip down to page 4 (of 5), it is about the x2xx
> family and recommends using XCAP_2, not XCAP_3. As an
> alternative, they suggest XCAP_1. Both XCAP_0 and XCAP_3 are
> not recommended.
>
> Were you aware?
>
> Jon
>
Thanks. I was not aware of the proper load cap of that crystal.
The delay between clearing OFIFG and testing it again, TI examples show a loop of 255. I think that is way too short if you start the code immediately after power up.
I did some test (code is shown below). In order to simulate power up in a debug session (where the target chip is always powered up), I disabled the LFXT1 oscillator, turn on the green LED, and wait for SW2 to be pressed. After that, I turn off the green LED, enabled the oscillator and proceed. Next I capture 4000 deltas and keep the max and min. And then I capture the sum of 16 more deltas. When all finished, I light up the red LED and loop forever.
You may use the debugger to reset the target and start to run. After you see the green LED, wait for various amount of time and press the SW2 button. The green LED will go off and the red LED will come on. At that time, use debugger to stop the CPU and examine the registers to see the max, min, and 16*delta.
My code is shown below. Note that it defines DLT as 255, the value TI uses. I think it is acceptable only if you pressed SW2 immediately after the green LED is on. If you want the delta to be decent enough after the chip was turned off for more than a few seconds, you need to change DLY to a much much bigger number.
BR
OCY
;=============================================================#include
#define DLY 255
ORG 0FFFEh
DC16 main
RSEG CODE
main: MOV.W #0x280,SP
MOV.W #WDTPW+WDTHOLD,&WDTCTL
MOV.B #BIT6,&P1OUT
MOV.B #BIT0+BIT6,&P1DIR
MOV.B #0,&P2SEL
L0: BIT.B #BIT3,&P1IN
JNZ L0 ;green LED is on, wait a while
; and press S2 to continue
MOV.B #0,&P1OUT
MOV.B #XCAP_2,&BCSCTL3
MOV.B #0xC0,&P2SEL
L1: BIC.B #OFIFG,&IFG1
MOV.W DLY,R15
L2: SUB.W #1,R15
JNZ L2
BIT.B #OFIFG,&IFG1
JNZ L1
MOV.B #XT2OFF+15,&BCSCTL1
MOV.W #4000-1,R4 ;count down from 4000
MOV.W #0,R5 ;max delta
MOV.W #0xFFFF,R6 ;min delta
MOV.W #CM_1+CCIS_1+SCS+CAP+OUTMOD_0,&TACCTL0
MOV.W #MC_2+ID_0+TASSEL_2,&TACTL
CALL #await_aclk
L3: MOV.W R15,R14 ;previous
CALL #await_aclk
MOV.W R15,R7
SUB.W R14,R7 ;delta
CMP.W R7,R5
JHS L4
MOV.W R7,R5 ;new max
L4: CMP.W R6,R7
JHS L5
MOV.W R7,R6 ;new min
L5: SUB.W #1,R4 ;repeat?
JNZ L3
MOV.W #16-1,R4 ;count down from 16
L6: CALL #await_aclk
SUB.W #1,R4 ;repeat?
JNZ L6
MOV.W R15,R7
SUB.W R14,R7 ;16*deltas
MOV.B #BIT0,&P1OUT
JMP $ ;red LED is on
; break here and view registers
; R5 = max of 4000 deltas
; R6 = min of 4000 deltas
; R7 = sum of next 16 (0x10) deltas
await_aclk:
await_aclk_01:
bit #CCIFG, &TACCTL0
jeq await_aclk_01
mov &TACCR0, r15
bic #CCIFG, &TACCTL0
ret
END
;=============================================================
--- In m..., Jon Kirwan wrote:
>
> On Tue, 17 May 2011 18:41:45 -0000, you wrote:
>
> >Okay, I assume that you did the following:
> >
> >main: MOV.W #0x280,SP
> > MOV.W #WDTPW+WDTHOLD,&WDTCTL
> > MOV.B #XCAP_3,&BCSCTL3
> > MOV.W #0,R15
> >L1: BIC.B #OFIFG,&IFG1
> >L2: SUB.W #1,R15
> > JNZ L2
> > BIT.B #OFIFG,&IFG1
> > JNZ L1
> > MOV.B #XT2OFF+15,&BCSCTL1
>
> OCY, something else comes to mind about your initialization
> code shown above. I hope you don't mind me bringing you back
> to this for a moment.
>
> You set up the Microcrystal to XCAP_3 loading. In the header
> file, just for anyone who doesn't already have it in mind,
> that is:
>
> #define XCAP_3 (0x0C) /* XIN/XOUT Cap : 12.5 pF */
>
> Which is the highest loading. Excessively high loading
> results in more power consumption, if I recall correctly and
> may slightly pull down the oscillation frequency.
>
> There is a file provided by Microcrystal, available on
> e2e.ti.com that covers this crystal and the Launchpad system
> from TI. It is at:
>
> http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer.Discussions.Components.Files/166/2772.TI_5F00_MSP430_5F00_Crystal-Recommendations.pdf
>
> If you skip down to page 4 (of 5), it is about the x2xx
> family and recommends using XCAP_2, not XCAP_3. As an
> alternative, they suggest XCAP_1. Both XCAP_0 and XCAP_3 are
> not recommended.
>
> Were you aware?
>
> Jon
>
Reply by ●May 19, 20112011-05-19
On Thu, 19 May 2011 22:02:07 -0000, OCY wrote:
>Jon,
>
>Thanks. I was not aware of the proper load cap of that crystal.
No problem. I had contacted Microcrystal in Europe when I
first got the Launchpad in the mail, because as I said before
I like to nail down every detail and the crystal in the kit
was an "unknown" to me. I got the datasheet and more
details, besides. Glad to pass that along.
> The delay between clearing OFIFG and testing it again, TI
> examples show a loop of 255. I think that is way too short
> if you start the code immediately after power up.
I completely agree. That link I pointed you at says about
450ms and unless their processor is running on the VLO, it's
too short. I am using 21000 right now for the default 1.1MHz
DCO rate. The loop is 3 clocks per, so that meets and
exceeds the "50us minimum" that is recommended. Of course,
even that is way too short. But it matches the docs and I
like to do that where there is doc, anyway.
> I did some test (code is shown below). In order to simulate
> power up in a debug session (where the target chip is always
> powered up), I disabled the LFXT1 oscillator, turn on the
> green LED, and wait for SW2 to be pressed. After that, I
> turn off the green LED, enabled the oscillator and proceed.
> Next I capture 4000 deltas and keep the max and min. And
> then I capture the sum of 16 more deltas. When all finished,
> I light up the red LED and loop forever.
>
> You may use the debugger to reset the target and start to
> run. After you see the green LED, wait for various amount of
> time and press the SW2 button. The green LED will go off and
> the red LED will come on. At that time, use debugger to stop
> the CPU and examine the registers to see the max, min, and
> 16*delta.
>
> My code is shown below. Note that it defines DLT as 255, the
> value TI uses. I think it is acceptable only if you pressed
> SW2 immediately after the green LED is on. If you want the
> delta to be decent enough after the chip was turned off for
> more than a few seconds, you need to change DLY to a much
> much bigger number.
>
Thanks so much, OCY. I don't have time right now, but I will
try it out and learn a few things along the way. Maybe make
some interesting modifications for my own thoughts.
Much appreciated. And thanks for the detailed discussion.
It's the kind of thing I really enjoy when the chance arrives
and I really do greatly appreciate the moments you've
offered.
Jon
>Jon,
>
>Thanks. I was not aware of the proper load cap of that crystal.
No problem. I had contacted Microcrystal in Europe when I
first got the Launchpad in the mail, because as I said before
I like to nail down every detail and the crystal in the kit
was an "unknown" to me. I got the datasheet and more
details, besides. Glad to pass that along.
> The delay between clearing OFIFG and testing it again, TI
> examples show a loop of 255. I think that is way too short
> if you start the code immediately after power up.
I completely agree. That link I pointed you at says about
450ms and unless their processor is running on the VLO, it's
too short. I am using 21000 right now for the default 1.1MHz
DCO rate. The loop is 3 clocks per, so that meets and
exceeds the "50us minimum" that is recommended. Of course,
even that is way too short. But it matches the docs and I
like to do that where there is doc, anyway.
> I did some test (code is shown below). In order to simulate
> power up in a debug session (where the target chip is always
> powered up), I disabled the LFXT1 oscillator, turn on the
> green LED, and wait for SW2 to be pressed. After that, I
> turn off the green LED, enabled the oscillator and proceed.
> Next I capture 4000 deltas and keep the max and min. And
> then I capture the sum of 16 more deltas. When all finished,
> I light up the red LED and loop forever.
>
> You may use the debugger to reset the target and start to
> run. After you see the green LED, wait for various amount of
> time and press the SW2 button. The green LED will go off and
> the red LED will come on. At that time, use debugger to stop
> the CPU and examine the registers to see the max, min, and
> 16*delta.
>
> My code is shown below. Note that it defines DLT as 255, the
> value TI uses. I think it is acceptable only if you pressed
> SW2 immediately after the green LED is on. If you want the
> delta to be decent enough after the chip was turned off for
> more than a few seconds, you need to change DLY to a much
> much bigger number.
>
Thanks so much, OCY. I don't have time right now, but I will
try it out and learn a few things along the way. Maybe make
some interesting modifications for my own thoughts.
Much appreciated. And thanks for the detailed discussion.
It's the kind of thing I really enjoy when the chance arrives
and I really do greatly appreciate the moments you've
offered.
Jon
