[MCF51JM128] Falling edge or rising edge on Input Capture

[Pogo]

Hi all,

I need to capture the falling edge and rising edge on input signal. I encountered one problem. That is when interrupt coming how do I recognized the coming event is rising edge event or falling edge event?

My thought is using the status of pin to determine which event is coming. The following code is my test.

... //Intial input capture     TPM1SC   = 0x0C;//CLKS = 01 : Bus rate clock - 24MHz, PS:100 : Divided-by 16. Timer clock : 1.5MHz     TPM1C2SC = 0x4C; //Input Capture on rising edge or falling edge   ... interrupt VectorNumber_Vtpm1ch2 void inputcapture_tpm1ch2(void) {     //clear flag     TPM1C2SC_CH2F = 0;     if( PTFD_PTFD2 )     {           //rising edge     }     else     {           //falling edge     } }  

But the result is always falling edge. Could any one give me any hint or suggestion?

Regards,

Pogo

[Monica]

Pogo, how is the project going? Any breakthroughs?

Regards!

[Pogo]

Hi Monica,

I changed MCU from MCF51JM128 to MC9S12XS128. I found that if I capture the signal and send data to PC by USB, it will spend too much time for sending data by USB. Then it will lost to capture the input signal.

So I will use MC9S12XS128 to capture the input signal and send data by UART to FTDI chip to PC through USB. The MCU can focus on capturing the input signal.

But I still need to solve how to capture the rising edge and falling edge in one IOC pin. I have five signal needed to capture and only have 8 IOC pin. If I capture those signals using two IOC pin, it needs ten IOC pin. I can't find any MCU which has 10 IOC pin in Freescale.

Anyway, Thanks a lot.

Regards,

Pogo

[TomE]

> I found that if I capture the signal and send data to PC by USB, it will spend too much time for sending data by USB.

Didn't you ask about this on another thread? Yes, here:

[MCF51JM128] USB Problem

Did you try my suggestions of using different interrupt priority levels for the data capture and USB data transfer?

How did it go?

Using two separate micros with separate code and a serial port between them is a very complicated way to do what this CPU should be able to support with some very simple programming. It shouldn't take more than 10 minutes to change the priorities and get this working.

In this thread someone was needing to capture both edges. You should read through it:

Freescale MCF5213 _DMA Timer_PWM pulse width calculation problem

The MCU you're using has plenty of input capture channels and they can be set up to capture on BOTH edges. As long as your interrupt latency is less than the minimum edge-to-edge spacing, then you should be able to capture all edges with this chip. You don't need one timer per edge.

Tom

[Pogo]

Hi Tom,

I've tried to change interrupt priority level for input capture. Even though it is better than previous, it still lost some input signals. I need to count the input capture signal, losing some input signals will cause my measure inaccurately. Finally I decide to use another MCU for my project.

Regards,

Pogo

[TomE]

The MCF51KM128 runs at 50MHz. It can run at one basic instruction per clock.  it should be able to keep up with quite high input data rates.

What are the maximum frequencies of the input signals, and what is the minimum edge-to-edge time that you have to measure in order to meet requirements?

The service routine for a timer interrupt should be as simple as:

1 - Read the pin (to verify which edge)

2 - Read the capture timer,

3 - Read/Write to ack the interrupt,

4 - Store the capture time

5 - Return

Alternately you can ACK the interrupt by writing the whole TPM1C2SC register with 0x48 on "odd" interrupts and 0x44 on "even" ones, alternating between rising and falling edge interrupts. The ISR may be slightly faster like this.

You should measure the exact interrupt service time. Then work out how fast it should be in theory, and then make the code more efficient after inspecting the generated assembly. The "worst case latency" (to service an interrupt) assumes that the other timer interrupts (and any other higher priority ones) have to be serviced first. Adding all this up should give you your minimum edge-to-edge time you can reliably measure. Compare that with the product requirements. The design will either meet the requirements or it won't.

I'm looking at the Reference Manual for this chip. It has a simple and inflexible interrupt structure. The interrupt priority levels are all hard-wired, The timers are at IPL5 and the USB is at IPL6. You can force interrupts to a higher priority, but only two of them (and you'd want all the timers and not just 2).

Higher featured chips (MCF52xx at least) have registers in the interrupt controller that let you read all the pending interrupts at once. That would allow for an interrupt service routine that handles all of the "pending" channels in a tight loop rather than exiting the interrupt and taking the next one. They also let you set the interrupt request levels of any peripheral to anything. Some chips have a TPM which can be programmed to do all the timer work for you.

You could always drop the USB priority level :in software. This involves taking the USB interrupt (at IPL6), disabling the USB interrupt by clearing TPM1C2SC, and then causing a lower software interrupt (say at IPL3) to run the actual USB interrupt service routine. When it completes it re-enables the IPL6 USB hardware interrupt by restoring TPM1C2SC.

Tom

[Pogo]

Hi Tom,

Thanks for your reply.

I've tried if I don't transmit any data to PC through USB. It will not lost input signals.

I used it for incremental rotary encoder. The frequency of input signal depends on its rpm.

Anyway, we decide to transfer system to MC9S12XS128.

Thanks a again.

Regards,

Pogo

[TomE]

> it needs ten IOC pin. I can't find any MCU which has 10 IOC pin in Freescale.

MCF51QE128? It has 12 timer channels. It doesn't have USB though, and you want a chip with both.

> So I will use MC9S12XS128 to capture the input signal

I was worried you might be going to a slower CPU, but that one is 40MHz, so it shouldn't be too bad.

Getting "time sync" between the two micros (so they agree on when things happened) might be interesting. In fact getting two (or three) separate timers in the same CPU running with the same counters might not be possible. You may end up with constant offsets between different timers you may have to measure and correct for.

Here's another possibility you may not have considered. Depending on how fine a timer resolution you require, you might be able to get a CPU with USB and a DMA controller. Then trigger to DMA controller to read an I/O port at (say) 100 kHz and write it to a ring-buffer in memory. The DMA controller is then sampling 8 I/O pins with a 10us resolution. The CPU is then programmed to scan through the ring buffer measuring when the I/O pin transitions occurred.

I can't find any MCF51 chips with DMA and USB, but the MCF52211 has an 80MHz CPU, USB, DMA, 4 16-bit and 4 32-bit timers  that can perform input capture, reassignable interrupt priorities and interrupt-pending registers.

> The frequency of input signal depends on its rpm.

And that maximum is?? Are you connecting to a 100,000 RPM centrifuge or a steam train? What is your calculated maximum interrupt latency? This is all a normal part of validating a system design and documenting it.

> I've tried if I don't transmit any data to PC through USB. It will not lost input signals.

So the timers can handle it, and it is the USB interrupt latency that is the problem.

That means the USB code is badly written. The interrupts should only take a very short time and signal background tasks to run, and that shouldn't interfere with your interrupts. It is doing things it shouldn't in the ISR. It might be possible to fix it or maybe you should buy a better one if the budget stretches to this.

Did you consider reassigning the USB interrupts in software like I suggested?

Tom

[TomE]

Here's another thing to watch out for.

How much control do you have of the signal you're monitoring?

I've worked on Remote Key Central Locking receivers for cars (for when you unlock your car with the remote on the key). Some of them have the demodulated radio signal interrupt the CPU to decode the transmission like you're doing. Then somewhere, something generates a radio signal in the same band the central locking is using with a very rapid signal modulation, say 100kHz or more.

Guess what that does to the receiver? Yes, it gets overloaded, spends 100% of its time in the interrupt service routine, the hardware watchdog bites and it gets reset. That's not too bad as long as that micro doesn't have anything else it should be doing in the car, but in my case it was also the dashboard CLOCK, and having it go back to "01:00" when this happens tends to be noticed. I had to have the interrupt code count how often it was being called, and if that was "too often" it had to disable the radio receiver for a while so as not to crash.

Watch out the same can't happen to you. If it is an "external signal" you should connect it to a signal generator and ramp the frequency up from DC to a few dozen MHz. Then write some code to detect/handle this, then test it again.

Tom

[Pogo]

I have over four signals need to monitor.

overloaded... OK~ I got it. I will test the frequency of signal which I need to capture. If it will spends 100% of its time for interrupt service. Oh! Bad news.

Anyway, Thanks for your reply.

Regards,

Pogo

[TomE]

Isn't TPM1C2 using pin PTF0/TPM1CH2? So you should be testing PTF0 and not PTF2. Tricky!

Make sure the edge-to-other-edge time is filtered in HARDWARE to be a lot slower than your code execution time. That's not just the time taken for the above interrupt, as some other interrupt service routine (or interrupt disable while programming Flash or something) may delay entry to that routine.

if you want to capture narrow pulses and guarantee to capture edges, then you should use two separate timers, one capturing each edge. Then as long as the waveform frequency is low enough you won't miss any edges or misinterpret a short pulse as the wrong polarity.

As an error check in your code, remember that each edge you see MUST be the OPPOSITE of the previous edge captured. If that test ever fails then you'll need to handle it and work out what went wrong.

Tom

[Pogo]

OK~ I will try it.

My previous product using MC9S12C to capture input signal's pulse width. In that product we use two pin to capture one signal. One pin is capture rising edge and the other pin is capture falling edge. It works fine.

In this case, I have many input signals need to capture. but hardware only have 8 pin for input capture. If I can capture one signal's pulse width by one pin not two pin. Then I will have more pins to capture input signal.