• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 1067 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.

TM4C123AE6PM: QEI direction changes occasionally

Norbert Toth
Expert 1145 points
Part Number: TM4C123AE6PM

Hi Folks,

I develop a brushed DC motion application, where I want to get the speed with direction from the QEI0. My problem is, that (for me, it seems) arbitrary number of times, discarding any periodicity, the direction flag in the QEI_O_STAT register toggles, however, it seems, that the motor rotates smoothly (without direction change).

The encoder that I have to use doesn't have index signal, so it is not connected to the CPU. The QEI configuration looks like:

MAP_QEIConfigure(QEI0_BASE, (QEI_CONFIG_CAPTURE_A_B | QEI_CONFIG_NO_RESET | QEI_CONFIG_QUADRATURE | QEI_CONFIG_NO_SWAP), 23);

MAP_QEIVelocityConfigure(QEI0_BASE, QEI_VELDIV_1, MAP_SysCtlClockGet() / 50 /*Hz*/);
MAP_QEIVelocityEnable(QEI0_BASE);

MAP_QEIIntEnable(QEI0_BASE, QEI_INTTIMER);
MAP_IntEnable(INT_QEI0 : INT_QEI1);

MAP_QEIEnable(QEI0_BASE);

And the interrupt handler, where I want to calculate the current RPM:

void HandleInterrupt() {
	MAP_QEIIntClear(QEI0_BASE, QEI_INTTIMER);

	// Direction compensated velocity
	float velocity = MAP_QEIDirectionGet(QEI0_BASE) * MAP_QEIVelocityGet(QEI0_BASE);
	_rpm = (velocity * 50 /*Hz*/ * 60) / 23 /*PulsePerCycle*/;
}

I checked it by print the value of _rpm via serial port or even if I place a break point into the HandleInterrupt() and check the appropriate HW register, I see, that the direction flag changes.

Can anybody help me? What could be the reason? What did I wrong?

Regards,

Norbert

  • 0
    Guru 117855 points

    I enjoyed your description and have encountered this several years past - although w/another vendor's ARM MCU.

    Two areas - to me - appear, "most likely:"

    • Your encoder is "glitching" its quad signals.   Now you were clever enough to "look for periodicity" - but the, "imprecision/variance of your motor's speed" - complicates & confounds that detection - does it not?  When my group faced this issue - we replaced the "encoder" with, "precisely timed & controlled digital signals" which "could not glitch" - and input those to the MCU's QEI Port - the problem vanished!   You may consider such a "test approach."
    • Should approach 1 (above) not prove convincing (or otherwise be bypassed) is it possible that your QEI stage, "accumulates counts" (that's just one theory) - and an "unwanted/unexpected Roll-Over" (or other violation) occurs - which (somehow) the MCU notes as a, "Direction change?"

    Sometimes - when trying to solve a difficult challenge - "Trying to "Break" (really to CAUSE) the issue to occur more quickly"- proves useful.    Returning to your (possible) use of controlled, proper quad inputs (my first suggestion) - perhaps you can systematically vary these - and "deliberately cause" the MCU to "illegally report" such direction change.   (maybe)

    As you are, "Driving a motor" - have you positively "ruled out" current spikes and/or other hi-energy transients - which may infiltrate your QEI inputs?    Have you tried to (both) shorten the encoder's quad outputs - perhaps even to "shield" them?    I believe that your MCU does support (internal, QEI Signal Filtering) - and so long as that is applied equally to both QEI inputs - that too - may prove helpful.

    Does this occur upon multiple boards?    Single board issues "eat" time/effort - absorb far more attention than justified...

  • 0 in reply to cb1_mobile
    Expert 1145 points

    Hi,

    you can see the schematic of the input circuit below:

    The HS0.A and HS0.B signals are connected to the MCU via a Schmidt trigger (74HC14). Is it not enough to filter out glitches? How should I design / rework the input stage of the QEI?

    Regards,

    Norbert

  • 0 in reply to Norbert Toth
    Guru 117855 points

    Thanks for the schematic - it does add neat detail - yet there (remain) many unanswered questions - limiting my/others' diagnosis...

    Perhaps your re-read of my initial post will prove more instructive than my (repeating) those questions, here.   I presented a, "Multi-Branch" diagnostic guide - yet (only) a single branch - captured your interest/response...

    Do note that it has NOT been (yet) established that your encoder is "glitching" - and the NEW DATA you've just presented (use of HC14) has (almost) eliminated "glitching" from consideration.   Still - it IS important that the HC14 be physically close to the encoder - insuring short/direct "encoder to HC14 input connections."

    The resistors & caps you've added to the MCU's QEI inputs should be "well matched in value." (so as NOT to negatively impact the encoder's timed, quad output)

    Of HIGH interest is the "unanswered" question regarding: "Number of boards (MCUs) & encoders - which exhibit this issue!"   (especially - do ANY assemblies work - w/out exhibiting this issue?)

  • 0 in reply to cb1_mobile
    Expert 1145 points

    Hi,

    I only detect this issue on single board. I turned on glitch filtering with the maximal value (the datasheet determines as system clock periods). It seems, to helped me, but doesn't eliminate the entire problem.

  • 0 in reply to Norbert Toth
    Guru 117855 points

    Norbert Toth said:
    I only detect this issue on single board.

    Does this imply that "this issue" does NOT occur upon (several) other boards?    If that's the case - the MCU and/or integrity of the QEI routings/connections - for that "single board" are suspect.