Interrupt Response time of MC9S12XDP512

[mlkarle]

We tried giving 5v TTL pulses on Interrupt Pin No.64 of MC9S12XDP512 controller.We observed that beyond 50khz of input frequency ,the controller was unable to recognize interrupts.Could you tell us the maximum frequency of the input that can be correctly identified as an interrupt and the response time of the interrupt module of the above controller.Our expected input frequency range is 18khz-240khz.Is there other way for the above controller to measure this frequency range.

[mke_et]

How much are you doing in your interrupt service routine?

Try this. Write the ISR so that it does NOTHING but set a flag and maybe save the internal timer counter word to a memory location and get out. Set the memory so that it increments a word counter on where to put the data. Once your buffer fills, stop and report the data. But do NOTHING IN THE ISR except SAVE THE DATA. No calcs, no responses, nothing but save the data if possible and get out.

THEN see how fast you can check.

ISR should be down in the sub-microsecond range, but you can't check for something new if your still looking at the something old.

I had an application where I was timing down to the 10uSec level, and found that when I used mechanical switches on a test box to input signals instead of the electrical interface I normally would use I was getting triggers on all the 'bounces' of the switches, and catching thousands of input triggers. And at that time, the 'first' arrival of the signal kept getting updated by the later arrivals, so in essence when I ran the test box I was not timing from button press, I was timing from the last 'bounce' before it stabilized. Once I change my ISR to account for that, I was dead nuts on with any input...

Response to the interrupt can be limited by other things going on in the system though. I tried to do too much in my interrupt service routines originally and found that I could time down to .0001sec reliably MOST of the time, but every now and then I found that I was getting 'windows' of almost 3msec of delay. Then I redid my ISRs so that all they did was snapshot and set a flag and get out. (Remember, it has to be not only the ISR that your interested that has to get in and out fast, it's ANY ISR that may trigger during the window that the ISR you're interested in may trigger that has to be fast!) I moved ALL processing of ISR info to a foreground task that was repeatedly called from a loop. Even serial com stuff. Got all my Rx and Tx data into ISRs, and made them as 'tight' as possible. As a result, I now time multiple events over 16 external interrupt pins (however, only 'any 2' can occur at any one time) and I am dead nuts on to less than .0001sec. Dead nuts enough that I can 'semi-reliably' take the internal TC count and use it to interpolate the time between .0001 ticks to give a reasonably accurate time down to .00001sec.

The hardware is fast. But you may have to look there to understand what is going on.

Mike

[kef]

Is PIn #64 PH0, PA7 or PS1? There are different XDP512 packages. Tell us what is pin function instead of pin number.

What code are you using. It may seem unable to recognise interrupts if your interrupt serivice routine is too long. BTW, what's bus clock? Did you enable PLL and made sure you are operating your chip at top speed? It should go above 50kHz easily but it depends on your software. The shortest possible S12X interrupt takes about 20 bus cycles, consult CPU12X reference manual to get exact figure. But again, it all depends on how many interrupts you have enabled, how long do they take, what about interrupt priorities etc etc.

Pulse accumulator (ECT module) is the right way to measure such high frequencies.

Regards

-

[mlkarle]

We are using Pin PH0 for interrupt recognition. We have set processor frequency at 32 Mhz , it is settable at 40 Mhz max. We are using processor expert tool with Codeworrior for programming. We tried our experiment with minimum code. There was only one interrupt defined. To measure the interrupt response we configured one I/O pin and by negating the value of this pin every time we have interrupt we monitor the interrupt response. There was no other operation in the interrupt. But using this , we were able to capture the pulses only upto 45kHz. We would like to go upto 240kHz. What could be done? 

[kef]

Be sure that it's not a slow CPU. I thought maybe it's pin interrupt glitch filter bug? Unfortunately I don't have 240kHz pulse generator at a hand at the moment and can't wire it to port H. But I tried it with port P. Interrupts were recognized up to max frequency of my low freq pulse generator (up to 133kHz only). All 133kHz pulses were recognized at 32MHz bus clock, at 16MHz bus clock and at 8MHz bus clock too. 4MHz bus clock is somewhat that could match your top 45kHz frequency. In my case it's 9+ cycles to recognise interrupt, 4 cycles to clear interrupt flag, 24 cycles to CALL function that sets LED pin DDRx bit and toggles the LED pin, 8 cycles to exit from interrupt handler. Roughly 50cycles. At 4MHz bus thats about 80kHz and it verifies experimentally quite well

Regards

-