• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 29 subscribers
  • Views 136 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C123AH6PM: QEISTAT Register ERROR bit - signal duration and reset

Bruno Saraiva
Guru 13040 points
Part Number: TM4C123AH6PM

Hi all,

QEISTAT Register has a bit called ERROR, which is set high "when an error was detected".

I could not find anywhere in the documents information regarding "for how long does that bit stay set". Does it briefly go high during the few clocks when two quadrature signals change at the same time, and right after it it goes back to zero? Does it go high once and never goes back to low???

If it briefly goes high, the Tivaware QEIErrorGet() function would not make too much sense, unless we are lucky enough to call it right during the error.

Regards

Bruno

  • 0
    TI__Guru**** 158695 points

    Hi Bruno,

     Glad to you hear you again. Hope you are doing well. 

    Bruno Saraiva said:
    Does it briefly go high during the few clocks when two quadrature signals change at the same time, and right after it it goes back to zero? Does it go high once and never goes back to low???

    In my opinion, the ERROR flag in the QEISTAT register is not sticky. If the ERROR bit is sticky (e.g. remains set after the error event) then there must be a way for the software to clear it. Without a way to clear the bit by software, the only way to clear the bit is for the peripheral reset. Therefore, I don't think the ERROR bit is sticky. Did you notice something that is different?

  • 0 in reply to Charles Tsai
    Guru 13040 points

    Hi Charles! All fine here, thanks, hope you are doing great!

    I totally agree that it is PROBABLY not sticky. I did not go into the trouble of creating an artificial "encoder error" signal to find out what the behavior is, because I don't have the HW available and was only adding some additional error check into our encoder library (yes, working on an encoder library without the error, what a fun thing to do!). Further explaining:

    So far our good old library does not check for the 'encoder error' situation, but we have recently been having a few units giving us weird distance data and that could be one reason, so I'm trying to diagnose "bad encoder" via software (probing the sensor in the real equipment is not easy).

    And then I got stuck on the question I posted... if it is not sticky, how can I be sure that I am reading the error bit "before it got back to zero"? Solution: I created an ISR to service encoder error, and in there I can check that the interrupt cause was the ERROR flag.

    But then, I'm not sure how to somehow be sure that the error is gone... We need to do that, because it is not impossible that a pair of QEI signals transition at the same time for a brief moment (the definition of the said 'error'), for example, when the encoder is powered up - and after that the encoder is 100% healthy but the software already detected "bad encoder" and remains stuck with that.

    Hope I made a clear explanation, I feel it is a bit confusing myself!   Slight smile

    Cheers

    Bruno

  • 0 in reply to Bruno Saraiva
    TI__Guru**** 158695 points

    Hi,

      I also don't have the hardware to verify QEI for this ERROR (both signals change at the same time.)

    Bruno Saraiva said:
    Solution: I created an ISR to service encoder error, and in there I can check that the interrupt cause was the ERROR flag.

    I will also try that too.  At the moment I don't think ERROR will cause the interrupt to generate. Per datasheet, the interrupt is generated for phase error, direction change, reception of the index pulse, and expiration of the velocity timer. If that is the case, if you are in the ISR, the ERROR flag may still read 0 even though it may have happened before you read it. 

  • 0 in reply to Charles Tsai
    Guru 13040 points

    Charles,

    I believe that the "ERROR" I described will indeed trigger the interrupt. As you pointed out, there are four events that can trigger QEI interrupt:

    1– Index pulse
    2– Velocity-timer expiration
    3– Direction change
    4– Quadrature error detection

    The error we are talking about seem to be exactly (from all I could read and understand) the #4 of this list. 

  • 0 in reply to Bruno Saraiva
    TI__Guru**** 158695 points

    Hi Bruno,

      Ok, thanks! I didn't know the ERROR flag in the QEISTAT register is another indication of the quadrature error as I thought quadrature error is more related to the phase error.