[mc9s12xs128] Doubt regarding simultaneous trigger of two timer i/p capture signals at the same time

[ndk]

Dear everyone, 

I am working with some application(mc9s12xs128) on which i have to use to two timer channels of ECT as input capture (say I use Timer Ch0, Timer Ch1) for two different continuous signals. And I use the trigger as 'capture on falling edge only'. The thing is when ever the falling edge occurs on any of these signals, I need to capture the time to some global variable from the respective Timer channel counters i.e. TC0, TC1 in this case.

But my doubt is what if the falling edge occurred on both the signals at the same time ? In this cases, I'm thinking either of the following two cases can happen. Please suggest me which one of the following two is correct.

Case:1

---------

1. First, CPU latches counter value (TCNT) to both channel counters TC0, TC1

2. Secondly then TC0 isr will execute as it has high priority than TC1.

3. Thirdly, TC1 isr will execute.

(or)

Case:2

----------

1. First, TC0 isr will execute after latching the TCNT value to TC0 counter.

2. Secondly, after completing TC0 isr, TC1 isr will execute after latching the TCNT value to TC1 counter.

If the Case:1 is correct, then may be that is not a problem for me.. Because i will have time. Otherwise if Case:2 is correct, i might loose the data of TC1 timer.

But anyway, if there is any other way, that i can successfully latch time at each falling of signal for the both the signals. I kindly request to please suggest me. Your experience can help me alot. Please find the my signal samples in the attachment.

Thank you

nandu

[kef · Accepted solution]

Case 1 is quite correct. On matching edge event, timer hardware immediately updates corresponding TCx register and sets corresponding TFLG1n flag. This can happen simultaneously to many timer channels. Information of what interrupts to execute (what interrupts are pending) is stored in interrupt flags registers. Interrupts can be globally disabled (CPU I bit is set), CPU can be executing some other ISR, but information about pending interrupts is not lost. As soon as I bit is cleared, CPU chooses highest priority pending interrupt and services it.

[ndk]

HI Kef,

Thanks alot Kef 

So, TC0 and TC1 data registers contains the latched TCNT counter value until the next interrupt occurs .. right..?

Thank you again,

nandu

[kef]

Not exactly. Capture registers contain latched TCNT value not until the next interrupt, but until the next active input capture edge. Even if you don't service capture event before next capture edge arrives, capture registers TCx still are updated.

ECT enhanced timer module allows to configure to update TCx on every capture event, or only after you service previous capture event (ICOVW register). But S12XS has standard timer module (TIM), not ECT, and TCx is updated on every capture edge.

[ndk]

Ohhh, Thank you Kef,

I am now cleared with this doubt

regards

nandu

[ndk]

Hi Kef and everyone,

With the same project as mentioned above, I am facing a strange problem now.

As I mentioned above, I am using two Input capture timer interrupts(negative edge) for two continuous signals and capturing the data.

But somewhere in the middle of the both the signals, I can see an un-necessary timer channel interrupt is occurring with out the negative edge detection.  I mean this error(un-necessary) isr call is occurring after the completion of the another signals isr. Please find the attached picture showing this scenario. May be you can understand the scenario after seeing the picture.

I attached my code snippet also in the attachment. The code has my application also by the way.

I tried many things but in vain. So, I would like to ask your help to solve this T_T.

Thank you ~~

nandu

[kef]

Could you zoom your input signals? S12XS specified typical input hysteresis is 250mV. Slow rising edge of your input signal should rise monotonically without any ~250mV steps in the opposite direction, else MCU can see false edges.

[ndk]

Hi kef,

unfortunately, I do not have the zoomed view of my input signals because of weekend.. . But I can post it on or before coming monday.

I think I understand what you are trying to explain. Say if my input signal slowly rising with a step  of +/-250ms in between.. there is a chance that timer module can detect the lower edge event at some point of time during the rising edge itself. Am  I understanding right ?.....correct me if I'm wrong please~

thank you

nandu

[ndk]

Hi,

I'm attaching the zoomed pictures of my signals in this post..

please check it and let me know if that picture is not clear or if you need some more kind of information.

thank you

nandu

[kef]

Thanks for oscillograms. They are clean enough and I don't see any spikes or somethink like that. I don't know, maybe rise time is too long or maybe specified typical 250mV hysteresis is not typical for your part. I think it's hardware issue, not software. It is easy to clear timer capture flags and lose interrupts by accidental read from capture registers (TFFCA=1 mode). But to set timer flag you have to toggle capture pin somehow. For this you should switch timer pin direction to output, but then oscillogram would look bit different...

[ndk]

Thanks alot Kef,

First of all, I'm not very clear about your below sentance

"But to set timer flag you have to toggle capture pin somehow. For this you should switch timer pin direction to output, but then oscillogram would look bit different.."

I wonder why I might need to switch the timer pin direction to output ?? (as I'm using timer channel as Input Capture).

Secondly,

Actually, both of my incoming continuous signals have high frequency of 20us. So, the input capture interrupt occurrence frequency is also high. So, do you think CPU load will be too much ??. And 

also, can this MCU (mc9s12xs128) support this kind of frequency ?? 

thank you

nandu

[kef]

Sorry for my english. I meant that it in case you wanted to trigger capture interrupt from software, you would need to switch timer pin direction to output and pulse active capture edge. It is not likely software causes those extra capture interrupts. I think it's hardware issue.

Regarding too high CPU load. On your oscillograms I didn't see missing interrupts. So I don't think you are facing too high load. BTW you can remove from your ISRs lines to disable and reenable specific timer channel interrupts TIExxx = y. Inside ISR all interrupts are disabled, unless you reenable them with CLI instruction.

Regarding input frequency. It depends on how long it takes to execute your ISRs and how often they all are triggered. I didn't try to compile your code, but it looks it should take less than about 80 cycles. At 25Mhz bus clock it's about ~3us. Having 2 such ISRs, you still have plenty of time to handle 1/20us frequency, 3+3 << 20.

[ndk]

Hi Kef,

Thank you again for clearing my doubts.

Currently I'm directly connecting my signal input l lines to Timer channel pins. As you suggested, may be I have to modify the signal interface with some kind of filters..I will discuss with my co-worker and I'll let you know about the status after modifying the hardware interface and test...hopefully it can be done by the end of this week~

Thank you 

nandu