This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28379D: Problem with eQEP

Part Number: TMS320F28379D

Hi all,

I try to run the eQEP for TMS320F28379D and using CCS with the F2837xD driver lib v3.05

After initialization of eQEP I check the position with "EQEP_getPosition" in an endless loop. Additionally I'm using an interrupt handler triggert by eQEP to check the Position Latch with "EQEP_getIndexPositionLatch".

After startup I move the encoder forward and get this:

pos: 0      {moving forward}
pos: 1
pos: 2
...
...
pos: 3998
pos: 3999
*IRQ*       (get position latch 3999)
pos: 0
pos: 1
pos: 2
...
...
pos: 3998
pos: 3999
*IRQ*       (get position latch 3999)
pos: 0
pos: 1
pos: 2
...
...

This looks good. After startup again but moving the encoder backward I get this:

pos: 2      {moving backward}
pos: 1
pos: 0
*IRQ*       (get position latch 0)
pos: 3999
pos: 3998
...
...
pos: 2
pos: 1
pos: 0
*IRQ*       (get position latch 0)
pos: 3999
pos: 3998
...
...

Looks great too. Everything looks fine as long as I moving the encoder in the same direction.

But now the Problem: When I pass the index in different directions I get a problem:

pos: 3995   {moving forward}
pos: 3996
pos: 3997
pos: 3998
pos: 3999
*IRQ*       (get position latch 3999)
pos: 0
pos: 1
pos: 2
pos: 3      {now moving backward}
pos: 2
pos: 1
pos: 0
pos: 3999
pos: 3998
pos: 3997
pos: 3996
*IRQ*       (get position latch 3996 and EQEP_INT_POS_CNT_ERROR)
pos: 3999
pos: 3998
pos: 3997
pos: 3996   {moving forward agian}
pos: 3997
pos: 3998
pos: 3999
pos: 0
pos: 1
pos: 2
*IRQ*       (get position latch 2 and EQEP_INT_POS_CNT_ERROR)
pos: 0
pos: 1
pos: 2
pos: 3
...

when still move forward and pass the index again after 360 deg then everythig OK again:wieder.

...
pos: 3998
pos: 3999
*IRQ*       (get position latch 3999)
pos: 0
pos: 1
pos: 2
...
...

The index interrupt comes to late after changing the direction and I not know why. Mostly the index interrupt comes 3

ticks too late, sometimes 2 ticks and sometimes up to 7 ticks.

To check if I have some hardware issues I configured the /A/B/I pins as normal input pins and print out what happen when

moving the encoder:

A B I
-----
0 0 0
1 0 0
1 1 0
0 0 1
1 0 0
1 1 0
0 1 0
0 0 0

This pattern don't change even if I change the direction.

This is my initialization code (based on a example from driver lib):

SysCtl_enablePeripheral(SYSCTL_PERIPH_CLK_EQEP3);

GPIO_setPadConfig(6, GPIO_PIN_TYPE_STD);
GPIO_setPadConfig(7, GPIO_PIN_TYPE_STD);
GPIO_setPadConfig(9, GPIO_PIN_TYPE_STD);

GPIO_setPinConfig(GPIO_6_EQEP3A);
GPIO_setPinConfig(GPIO_7_EQEP3B);
GPIO_setPinConfig(GPIO_9_EQEP3I);

Interrupt_register(INT_EQEP3, &index_interrupt_handler);
Interrupt_enable(INT_EQEP3);

EQEP_setDecoderConfig(EQEP3_BASE, (EQEP_CONFIG_1X_RESOLUTION |EQEP_CONFIG_QUADRATURE | EQEP_CONFIG_NO_SWAP));
EQEP_setEmulationMode(EQEP3_BASE, EQEP_EMULATIONMODE_RUNFREE);
EQEP_setPositionCounterConfig(EQEP3_BASE, EQEP_POSITION_RESET_IDX, ENCODER_MAX_TICKS - 1);
EQEP_enableUnitTimer(EQEP3_BASE, (f2837x::system::get_cpu_clock_speed() / 100));
EQEP_setLatchMode(EQEP3_BASE, EQEP_LATCH_UNIT_TIME_OUT);
EQEP_enableInterrupt (EQEP3_BASE, EQEP_INT_INDEX_EVNT_LATCH | EQEP_INT_UNDERFLOW | EQEP_INT_OVERFLOW | 

EQEP_INT_POS_CNT_ERROR | EQEP_INT_PHASE_ERROR);
EQEP_enableModule(EQEP3_BASE);
EQEP_setCaptureConfig(EQEP3_BASE, EQEP_CAPTURE_CLK_DIV_64, EQEP_UNIT_POS_EVNT_DIV_32);
EQEP_enableCapture(EQEP3_BASE);

I also tested latch mode EQEP_LATCH_RISING_INDEX and EQEP_LATCH_FALLING_INDEX with same result.

Any help would be appreciated,

Martin

  • Hi Martin,

    Yes you are right , there is some issue with position counter getting incorrectly reset on Direction Change During Index. It is a known issue and is captured in the device errata. Please refer below for detailed description and work around.

    This issue would be resolved in the next release. Please let me know if you have any other concerns.

    Regards

    Himanshu

  • Hi Himanshu,

    I'm the FAE responsible for this customer. Unfortunately the customer needs the Index Pulse for their application. Is there an alternative workaround to this? Will this be solved with the next release of the driver library or is it a silicon issue? When is the next driver release scheduled?

    Regards

    Mihir Gupta

  • Thanks Himanshu for this information.

    The workaround not to use PCRM=0 not really help because then I not get an interrupt anymore when passing the Index (maybe this behaviour is a bug too).

    Think we must wait for a fix in the next rev.

    thanks again, Martin