AVR-Chat

I am using TDC0 to time an incoming event.

At time 1 I set
 TDC0.CNT = 0x0000;
 TCD0.CCA = 0x0000;
 TCD0.PER = 0x065F;
 TCD0.CTRLA = TC_CLKSEL_DIV1_gc;

EVENT0 is supposed to capture the CNT into CCA when PortB pin1 signall is Rising.

I have added an overflow function (which is why "TCD0.PER = 0x065F;") in case there is no signal coming in and I set everything to defaults.

With no signal coming in (results are set to defaults).

at time 1
 TDC0.CNT = 0x0000 TCD0.CCA = 0x00 TCD0.PER = 0x065F
 TDC0 set to TC_CLKSEL_DIV1_gc
at time 2
 TDC0.CNT = 0x0254 TCD0.CCA = 0x00
at time 3
 TDC0.CNT = 0x03ce TCD0.CCA = 0x00

When TCD0 hits the overflow interrupt
 TDC0.CNT = 0x0043 TCD0.CCA = 0x00 TCD0.PER = 0x065f
 TDC0 set to TC_CLKSEL_OFF_gc

At end of Cycle
TDC0.CNT = 0x00b3 TCD0.CCA = 0x00

Now if I send in a pulse that causes Event0 (PortB1 rising) to capture the count this is what I get

at time 1
 TDC0.CNT = 0x0000 TCD0.CCA = 0x00 TCD0.PER = 0x065F
 TDC0 set to TC_CLKSEL_DIV1_gc
at time 2
 TDC0.CNT = 0x0255 TCD0.CCA = 0x00
at time 3
 TDC0.CNT = 0x03cf TCD0.CCA = 0x8260 (varies up to 8295)

When TCD0 hits the overflow interrupt
 TDC0.CNT = 0x003d TCD0.CCA = 0x8260 TCD0.PER = 0x065f
 TDC0 set to TC_CLKSEL_OFF_gc

At end of Cycle
 TDC0.CNT = 0x00ad TCD0.CCA = 0x8260

Why the HUGE number in CCA? I would think it to be around 0x0420 from tests on a previous system (using a 16A4).

If I add 0x7FFF to the 0x8260 then it looks like a sane/reasonable number for what I expecting.  So why is it so weird?

Is there something I'm doing wrong in my set up?
Before there was no Overflow in TCD0. Is there a problem with having a Capture and Overflow in the same timer?
I tried moving the Overflow out and doing the overflow processing on TCE1, but TCD0 is still out of it.

wade

--- In AVR-Chat@yahoogroups.com, "warm38spl" <warm38@...> wrote:
>  TDC0.CNT = 0x0000;
>  TCD0.CCA = 0x0000;
>  TCD0.PER = 0x065F;
>  TCD0.CTRLA = TC_CLKSEL_DIV1_gc;

Either you didn't show us all of your initialization or you're missing something.  You also need something like shown below (insert prior to the write to CTRLA), assuming the use of event channel 0.

TCD0.CTRLB = TC0_CCAEN_bm;
TCD0.CTRLD = TC_EVACT_CAPT_gc | TC_EVSEL_CH0_gc | 0x0002;

You also didn't show your event channel configuration or the configuration of the pin for event generation so there could be something wrong with those, too.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

--- In AVR-Chat@yahoogroups.com, "Don Kinzer" <dkinzer@...> wrote:
>
> --- In AVR-Chat@yahoogroups.com, "warm38spl" <warm38@> wrote:
> >  TDC0.CNT = 0x0000;
> >  TCD0.CCA = 0x0000;
> >  TCD0.PER = 0x065F;
> >  TCD0.CTRLA = TC_CLKSEL_DIV1_gc;
> 
> Either you didn't show us all of your initialization or you're missing something.  You also need something like shown below (insert prior to the write to CTRLA), assuming the use of event channel 0.
> 
> TCD0.CTRLB = TC0_CCAEN_bm;
> TCD0.CTRLD = TC_EVACT_CAPT_gc | TC_EVSEL_CH0_gc | 0x0002;

At the startup that stuff is handled by the code generated by the CodeVisionAVR Wizard.  The code I was showing was my own which was added to do the job.  OK here is the CVAVR startup code snippets:

For TDC0:
    TCD0.CTRLA=(TCD0.CTRLA & (~TC0_CLKSEL_gm)) | TC_CLKSEL_DIV1_gc;
    // Mode: Normal Operation, Overflow Int./Event on TOP
    // Compare/Capture on channel A: On
    // Compare/Capture on channel B: Off
    // Compare/Capture on channel C: Off
    // Compare/Capture on channel D: Off
    TCD0.CTRLB=(TCD0.CTRLB & (~(TC0_CCAEN_bm | TC0_CCBEN_bm | TC0_CCCEN_bm | TC0_CCDEN_bm | TC0_WGMODE_gm))) |
        TC0_CCAEN_bm |
        TC_WGMODE_NORMAL_gc;

    // Capture event source: Event Channel 0
    // Capture event action: Input Capture
    TCD0.CTRLD=(TCD0.CTRLD & (~(TC0_EVACT_gm | TC0_EVSEL_gm))) |
        TC_EVACT_CAPT_gc | TC_EVSEL_CH0_gc;

For Events:

    // Event System Channel 0 source: Port B, Pin1
    EVSYS.CH0MUX=EVSYS_CHMUX_PORTB_PIN1_gc;

For PortB Pin 1:

    PORTB.PIN1CTRL=PORT_OPC_TOTEM_gc | PORT_ISC_RISING_gc;

Now back to my original questions...
I took out the overflow from TDC0, but that didn't help, it still shows 0x8...  I did notice when I used an inverter to generate the signal and CCA held CNT+0x8000.  Exactly.

Before (on the 16A4) the testing that the other guy did showed about 1056 (0x0420) plus/minus a little in CCA.  Why is mine 0x8000 over?
Did the processor hear my negative spoken comments about its ancestry and decide to go negative to get back at me?

> You also didn't show your event channel configuration or the configuration of the pin for event generation so there could be something wrong with those, too.
> 
> Don Kinzer
> ZBasic Microcontrollers
> http://www.zbasic.net
>

Pulling at straws...
-Do you have a 16A4 to try this on?
-Did you tell the environment that you're using a 64A4?
-Could it be a memory address? There's more in the 64A4; 0x8000 is 32K that was not available in the 16A4 but is in the 64A4...
 
Good luck,
 
Cat
 

> 
> Before (on the 16A4) the testing that the other guy did showed about 1056 (0x0420) plus/minus a little in CCA. Why is mine 0x8000 over?
> Did the processor hear my negative spoken comments about its ancestry and decide to go negative to get back at me?
> 
 		 	   		  

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

Yes, the compiler knows that I'm working with the 64A3 not the 16A4.
I have not worked with the 16A4 only the 64A3.  But then, everything else works just fine.  The only problem the extra 0x8000 in the CCA.  Why is it there?  It's driving me nuts! (or, at least, more so than is normal for me)

--- In AVR-Chat@yahoogroups.com, Cat C <catalin_cluj@...> wrote:

>
> 
> Pulling at straws...
> -Do you have a 16A4 to try this on?
> -Did you tell the environment that you're using a 64A4?
> -Could it be a memory address? There's more in the 64A4; 0x8000 is 32K that was not available in the 16A4 but is in the 64A4...
>  
> Good luck,
>  
> Cat
>  
> 
> > 
> > Before (on the 16A4) the testing that the other guy did showed about 1056 (0x0420) plus/minus a little in CCA. Why is mine 0x8000 over?
> > Did the processor hear my negative spoken comments about its ancestry and decide to go negative to get back at me?
> > 
>  		 	   		  
> 
> [Non-text portions of this message have been removed]
>

End of one problem and start of another.

The documentation (the version newer than the one I had) indicates that if PER is LESS THAN 0x8000, then CCA will contain 0x8000 for a Rising edge or 0x0000 for a Falling edge causing the input capture.  The number I used was much less than 0x8000, so that was the problem and all I needed to do is AND off the Rising-Edge indicator.

Now for the continuing saga...
Everything is now looking good ... except ...
I set up TCE1 for timing pulses as they are generated, and my oscilloscope agrees with what the TCE1.CNT says.

TCD1 is used by setting TDC1.PER to the time for the next signal.
As in
Code:
    VPORT2.OUT |= SIG_ENT_ON;
    tcd0inta = TCE1.CNT;  /* ### for DEBUG timing ### */
    TCD1.PER = nextIntrTime;

Also, as I said earlier I'm using TDC0 to find when an event occurs (do input capture on EVENT0 B1 rising). If no event occurs, I have set up TCD0 with the overflow of 0x65F.

Here is the weirdness that I am experiencing:

A signal occurs at 62 microSec. Running at 32MHz means it occurs at 0x7C0 cycles. And 50 microSec after that signal will come the final signal at 112 microSec which is 1600 (0x640) cycles or 50uSec later (subtracting out the instructions to set up the signal is about 60). I set TCD1.PER to 0x640 (to fire at 112uSec) but it fires at 0x8a6=69.1uSec (62uSec=7C0 cycles, diff is E4=228 cycles, not the 1600 I put in there). I even tried setting TCD1.PER to 0x80 and 0x1000 and it STILL fires about the same time +/- 4cycles.

Also, the afore mentioned TCD0 overflow is supposed to fire at about 66uSec out of 112 uSec. It ALWAYS fires AFTER the 0x8A4 time of the "final" signal (0x8BA=69.8uSec). I tried to get it to fire earlier or later, but setting TCD0.PER does not seem to make any difference either when I'm coming to to final signal in the sequence.

So, any ideas why TCD0.PER and TCD1.PER appear to ignore the values I put in them? I do the same sequence for all the other signals and only on this one signal do they ignore me. I don't like my processors to ignore me. (insert glare at processor here)

Any suggestions as to what I should try looking for?
I dump out PER CNT CCA for TCD1 and at every signal I use TCE1.CNT to get the timing of each signal. My O'scope agrees with TCE1.CNT, so I know TCE1 is working, but what happens to TCD0 and TCD1 and firing off the overflow whenever it wants to, not based on PER?

wade

Problem found!  I cannot explain it, but it works 100%.

I noticed that the numbers I use are equal or progressively smaller and all is OK, until I want to put in a bigger number.  The previous number was about 6 uSec (192 cycles) and that was the time when it SHOULD have been 50 uSec (1600 cycles).

I tried a few things in the ISR.
1 If I set both .PER and .PERBUF, no help.
2 If I clear INTFLAGS BEFORE I set .PER, no help.
3 If I clear INTFLAGS AFTER I set .PER, IT WORKS!

Why?  I don't know, but it works and I can put bigger numbers into .PER and get proper signal durations.

Anybody with an explanation?  I can't find any mention in the docs (8077.pdf Section 14).

wade


--- In AVR-Chat@yahoogroups.com, "warm38spl" <warm38@...> wrote:

>
> End of one problem and start of another.
> 
> The documentation (the version newer than the one I had) indicates that if PER is LESS THAN 0x8000, then CCA will contain 0x8000 for a Rising edge or 0x0000 for a Falling edge causing the input capture.  The number I used was much less than 0x8000, so that was the problem and all I needed to do is AND off the Rising-Edge indicator.
> 
> Now for the continuing saga...
> Everything is now looking good ... except ...
> I set up TCE1 for timing pulses as they are generated, and my oscilloscope agrees with what the TCE1.CNT says.
> 
> TCD1 is used by setting TDC1.PER to the time for the next signal.
> As in
> Code:
>     VPORT2.OUT |= SIG_ENT_ON;
>     tcd0inta = TCE1.CNT;  /* ### for DEBUG timing ### */
>     TCD1.PER = nextIntrTime;
> 
> Also, as I said earlier I'm using TDC0 to find when an event occurs (do input capture on EVENT0 B1 rising). If no event occurs, I have set up TCD0 with the overflow of 0x65F.
> 
> Here is the weirdness that I am experiencing:
> 
> A signal occurs at 62 microSec. Running at 32MHz means it occurs at 0x7C0 cycles. And 50 microSec after that signal will come the final signal at 112 microSec which is 1600 (0x640) cycles or 50uSec later (subtracting out the instructions to set up the signal is about 60). I set TCD1.PER to 0x640 (to fire at 112uSec) but it fires at 0x8a6=69.1uSec (62uSec=7C0 cycles, diff is E4=228 cycles, not the 1600 I put in there). I even tried setting TCD1.PER to 0x80 and 0x1000 and it STILL fires about the same time +/- 4cycles.
> 
> Also, the afore mentioned TCD0 overflow is supposed to fire at about 66uSec out of 112 uSec. It ALWAYS fires AFTER the 0x8A4 time of the "final" signal (0x8BA=69.8uSec). I tried to get it to fire earlier or later, but setting TCD0.PER does not seem to make any difference either when I'm coming to to final signal in the sequence.
> 
> So, any ideas why TCD0.PER and TCD1.PER appear to ignore the values I put in them? I do the same sequence for all the other signals and only on this one signal do they ignore me. I don't like my processors to ignore me. (insert glare at processor here)
> 
> Any suggestions as to what I should try looking for?
> I dump out PER CNT CCA for TCD1 and at every signal I use TCE1.CNT to get the timing of each signal. My O'scope agrees with TCE1.CNT, so I know TCE1 is working, but what happens to TCD0 and TCD1 and firing off the overflow whenever it wants to, not based on PER?
> 
> wade
>