• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 223 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.

TMS320F28388D: Can the QEP index event be cleared at run-time?

jimj2713
Expert 2375 points
Part Number: TMS320F28388D


We have some IO-pins that are used for 2 purposes, and 1 purpose is the QEP. I believe that switching the GPIO functions from GPIO to QEP is causing an index-event within the peripheral. Then the next position-edge causes a false position-count reset. 

I tried setting QCLR.bit.IEL = 1, but that did not work; can the index-event within the peripheral be reset at run time?

Thanks,

Jim

  • 0
    TI__Genius 15385 points

    Hi Jim,

    Writing. QCLR.IEL=1 should clear the IEL flag in the QFLG register, i.e. QFLG.IEL=0. I did verify it at my end, and it does work as described.

    Can you please give out the details on sequence of events?

    Also, can you make sure that eQEPI signal is not glitchy, because that can cause frequent trigger on IEL flag?

    Best Regards,

    Nirav

  • 0 in reply to Nirav Ginwala
    Expert 2375 points

    Nirav,

    Thank you for the quick reply. I am using the QEP in reset-on-index mode (PCRM=0), and the QEP GPIOs (96, 97, and 99) are being switched from GPIO-inputs to QEP functions. After switching the GPIO mux, I set QCLR.bit.IEL = 1. At this moment, QFLG.bit.IEL = 0 and QEPSTS.bit.FIMF = 0. On the next edge-transition of A/B, QFLG.bit.IEL and QEPSTS.bit.FIMF are both set to 1, and the QPOSCNT is reset to 0 -- this is not at the actual index location.

    I suspected the same thing -- some kind of glitch on the index line, but I have a very reproducible test scenario, and one solution to this problem is simply leaving the GPIO pins set to the QEP mux. This is a less desirable solution because I would be losing a product feature this way. 

    I suspect the QEP peripheral is seeing some internal glitch, and then it is waiting for the next quadrature edge as described in the "Position Counter Reset on Index Event" section of the TRM. I was hoping I could clear this internal state. 

    Thanks,

    Jim

  • 0 in reply to jimj2713
    TI__Genius 15385 points

    Hi Jim,

    What you are seeing is an expected behavior, when you switch GPIO mux to QEP you will see a glitch, it also depends on what is the state of GPIO before you switch it to eQEP. And once that glitch is seen by eQEP it will consider that as an INDEX event and on the next QCLK it will reset the QPOSCNT. 

    One solution that you can try is, make sure the GPIO is in input mode, and drive "0" or "1" to it before you switch the mux to eQEP. 

    Best Regards,

    Nirav 

  • 0 in reply to Nirav Ginwala
    Expert 2375 points

    Nirav,

    The GPIO pins are inputs, and the external connections to the board are not changing during this process (so the logic states outside the DSP are not changing). It really does look like simply changing the GPIO mux may cause a glitch into the QEP.

    Thanks,

    Jim