High Speed quadrature

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

High Speed quadrature

662 Views
guillaumetiffin
Contributor III

Hello,

I'm using the quadrature on the FTM1 of my K60 and MQX4.0.

The peripheral source clock of my FTM is 60Mhz.

I'have an issue when the overflow occurs too often.

If I have a vibration on my quadrature input, I can have the case where the module count +1 and -1 really quickly.

If the counter is at the value 0, it has the effect to create many interruption and really quickly.

In my interruption routine, I test the differents cases to know if the overflow occurs on the bottom or on the top of counting.

To add a security, I read the count register and I check if the value match with the overflow flag. (Example : there is an top counting interrupt. In the count value you must have something close to 0 and never 0xFFFF)

The problem is that in somes cases I have some incoherence which occurs.

Sometimes instead to have +1/-1/+1 etc..., I have many +1 for one -1

This behaviours start to appears at a vibration of 30 kHz.

I tested with an oscilloscope to see the time duration of my interrupt. The interrupt is handled 2µs after the overflow occurs and my interrupt takes only 0.5µs.

During the interrupt, there is no more overflow. (I have enought time to do my test and go out the interrupt before an new overflow occurs)

I read the 2 values that I need and I clear the flag

_DirectionRegister = FTM1_BASE_PTR->QDCTRL;

_CodeurValue = FTM1_BASE_PTR->CNT;

FTM_PDD_ClearOverflowInterruptFlag(FTM1_BASE_PTR);

Why there is some incoherences?

I would like to know how to manage those cases?

If you need more details doesn't hesitate to ask it.

Regards,

Guillaume

0 Kudos
3 Replies

427 Views
EarlOrlando
Senior Contributor II

Hello Guillaume,

As you said, this is an issue generated by the nature of your system. This case is described in the section 42.4.25.1 Quadrature Decoder boundary conditions in the MK60 Reference Manual​.

pastedImage_2.pngpastedImage_1.png

Fortunately, the FlexTimer module offers a filter for each channel which helps to avoid glitches that may cause oscillation in the module. Please enable these filters.

pastedImage_5.png

Best regards,

Earl Orlando.

0 Kudos

427 Views
guillaumetiffin
Contributor III

Hello,

I have already tried this.

The problem is that I can only filter frequency higher 4Mhz and my pulse is 500Khz.

It is not a glitch as you supposed. It a vibration on my codeur.

The main problem that I have is in the interruption.

The values in the register are not corrector when I proceed the interruption, the values are changing.

Regards,

Guillaume

0 Kudos

427 Views
egoodii
Senior Contributor III

Is your 'rollover' interrupt priority set higher than ANY other interrupt source, and is ANY other potential 'interrupt disable' operation performed NOT by an actual 'disable interrupts' but instead by setting the minimum interrupt-level to that of this rollover?

I do this:

             for (n = 0; n < 92; n++)
                            set_irq_priority(n, (1 << (ARM_INTERRUPT_LEVEL_BITS-1)));  //Default everybody to middle priority
/* Init encoder interrupts */
enable_irq(INT_FTM1-16);
set_irq_priority(INT_FTM1-16, 0);//Highest priority, for timely handling of 16-bit overflow count extension
            //Also makes the encoder IRQ handlers Uninterruptible.

And use these macros for 'enable'/'disable' of general interrupts:

PUBLIC uint32_t Port_IntsDisableCount; // count of performed disables

#define DISABLE_PORT_INT()    Port_IntsDisableCount++;\

                              __set_BASEPRI( 0x10L );        //All SPI-device interrupts on Level 1, disable them (and lower)

#define ENABLE_PORT_INT()      if(--Port_IntsDisableCount==0) \

                                    __set_BASEPRI( 0 );      //If we get back to 'base level', enable all interrupts

0 Kudos