• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 593 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Encoder counts up with no input

Don McCune
Intellectual 385 points

I am using a recent version of controlSUITE and CCS version 5.1.0.09000.  I am using the controlCARD TMDXCNCDH52C1 with the XDS100v2 emulator. 

I am running the example eqep_pos_speed_c28.  Instead of attaching the encoder inputs to the PWM output signals, I tie all of the inputs together.  So I have GPIO's 20, 21, and 22 tied together -- not 23 because I am not concerned with index pulse.  This should make sure that the encoder has no input signal, so I would expect the value to start at zero and stay there.  On the m3 I run the setup_m3 project.

I put a breakpoint on line 138 of Example_posspeed.c in the function POSSPEED_Calc to view the position value for the encoder.  This is one line below the following:

pos16bval=(unsigned int)EQep1Regs.QPOSCNT;     // capture position once per QA/QB period

When I examine the value of pos16bval, I get a value, for example 7522.  If I simply run till I hit the breakpoint again, the number increments a small amount, e.g. 7588.  If I remove the breakpoint temporarily and let it run, then stop it again, the value increments some amount relative to the amount of time it has run.  For example if I run for about five seconds it goes to 10,344.

When I originally ran this example, I had the PWM leads going into the encoder inputs as suggested and I thought I had a working system, since I saw the encoder value incrementing.  But now I see that the incrementing value was not related to the signals going into the encoder inputs, rather it was just the passage of time.

Why is EQep1Regs.QPOSCNT changing value with no signal on the encoder input lines?  What can I do to make it work correctly.

 

  • 0
    TI__Genius 15260 points

    Don,

    What happens if you tie them to GND or 3V3 instead of tying them together?  Are pull ups enabled on these pins?  These are inputs when configured as QEP so they may be floating and spontaneously latching values.  Not sure what the expected behavior is when you externally connect input pins.

    Kris

  • 0 in reply to Kris Parrent
    Intellectual 385 points

    Your answer sent me looking in the right direction.  I found that the encoder that I was using was not getting sufficient power; once that was fixed, I can now count actual encoder counts and when the encoder is not moved the counts stay constant.  That was my objective all along.

    I am assuming that GPIO22 is the return for the A+ and B+ signals.  In the code it is identified as "EQEP1S", but I do not know what "S" means.  Am I right?  If not, do I just use any ground on the board for A- and B-?

    Regarding pullups, I believe these lines in setup_m3.c enable pullups for these IO on port A.

    // Enable Pullups on EPWM(1-8)A/B capable pins

    GPIOPadConfigSet(GPIO_PORTA_BASE, 0xFF, GPIO_PIN_TYPE_STD_WPU);

    GPIOPadConfigSet(GPIO_PORTB_BASE, 0xFF, GPIO_PIN_TYPE_STD_WPU);

    I assume that the Concerto uses a double ended input comparator, in which case I understand why tying the lines together without a power source could result in chatter that could cause the incrementing counter that I saw.

  • 0 in reply to Don McCune
    TI__Genius 15260 points

    Don,

    Glad to hear you got this working.  The EQEP1S is a strobe signal.  Your application may not need it.  You can reference the EQEP UG on pg 846 here for the signal description:

    http://www.ti.com/lit/ug/spruh22b/spruh22b.pdf

    As far as the pull ups go, that command is enabling the pulls on Ports A and B.  However, I believe the QEP pins are on PORTD (reference pg 59 of datasheet http://www.ti.com/lit/ds/symlink/f28m35h52c.pdf).  The pulls are not required as long as you're actively driving the pin one way or the other, but they may help clear up strange behavior such as you were experiencing.  Sounds like you have it fixed though.

    EDIT:  Yes any ground on the board will work fine.

    Kris

  • 0 in reply to Kris Parrent
    Intellectual 385 points

    I followed the link that you sent me regarding the QEP pins.  I found the following lines on page 59 but I cannot see how to tell what port they are on.  I assumed the lines were on port A because the code uses, for example, GpioCtrlRegs.GPAQSEL2.bit.GPIO20, not GPDQSEL2.  Please help me understand.

    PD4_GPIO20 GPIO20 EQEP1A MDXA
    PD5_GPIO21 GPIO21 EQEP1B MDRA  

    PD6_GPIO22 GPIO22 EQEP1S MCLKXA –

    PD7_GPIO23 GPIO23 EQEP1I MFSXA –

     

  • 0 in reply to Don McCune
    TI__Genius 15260 points

    Don,

    The Port is in the M3 world, so you look at what the pin is referred to by the M3 to find this out.  So for your GPIOs:

    PD4_GPIO20

    The PD4 means that this is Port D Pin 4 on the M3.  Since the M3 is the master which controls the ownerships and pull ups and such, you will always refer to the M3 pin name when configuring the pin from the master subsystem.

    I can see how GPAQSEL can be confusing, but this is legacy C28x register naming.  C28x register names have no impact on this.

    Kris