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: QEP Counter change upon phase error

Part Number: TMS320F28388D

Tool/software:

Hi Experts,

My customer is observing common mode interference on the QEP interface like below:

The red frame marks the interference that will cause a phase error

The TRM said

The phase error flag (PHE) is set in the QFLG register and the QPOSCNT value can be incorrect and offset by multiples of 1 or 3

In this case, the value of QPOSCNT is not correctly anymore, and the error would accumulate as the interference happens for multiple times. Therefore, customer would like to compensate for the QPOSCNT error cause by phase error. 

Is there a way to know the exact changes of QPOSCNT when phase error happens? Customer is trying to compensate for the unexpected changes caused by phase error in the next cycle.

If not, is there a way to make QEP ignore such interference and carries on counting? (The system has run out of CLB blocks)

Regards,

Hang

  • Hi Hang,

    Thanks for reaching out and appologies for the delayed response.

    Can you please provide additional details on the signals in the scopeshot?

    Is the lower image just a zoomed in view from the upper image?

    Can you confirm the GPIO configuration for these EQEP pins?

    Have you tried using 3/6-sample syncronization before feeding the signal to the EQEP module?

    You mentioned that there are no CLB blocks left in the system, have you used the CLB to account for this issue in another design? If so, what did that solution look like?

    Best Regards,

    Zackary Fleenor

  • Hi Fleenor,

    Can you please provide additional details on the signals in the scopeshot?

    The green and purple are QEP-A and QEP-B respectively, you may ignore the rest. As you can see, there is common mode interference on these two signal.

    Is the lower image just a zoomed in view from the upper image?

    Yes.

    Can you confirm the GPIO configuration for these EQEP pins?

    I assume the configuration concerned is the 3/6-sample synchronization. Customer has tried all both 3/6 synchronization and the issue are the same.

    ave you used the CLB to account for this issue in another design? If so, what did that solution look like?

    Previously CLB are used for absolute encoder interfaces. They later managed to free 4 tiles from the absolute encoder interfaces to handle this QEP issue.

    For now, we are planning to use the QEP on CLB solution. In this way the QEP counter would not change unexpectedly upon phase error, and they will compensate for the counting error by software according to the times of phase error. 

    Coming back to the original question. Is there a way to know the exact changes of QPOSCNT when phase error happens?  Note that we are using CLB only because the "QPOSCNT" of the CLB (or, the CLB counter) would not change expectedly. If the origin QEP module can achieve the same, it would make the system simpler.

    Regards,

    Hang

  • Dear Hang,

    Thank you for providing those details about your implementation plans using the CLB solution.

    Regarding your question about tracking QPOSCNT changes during phase errors - unfortunately, there isn't a direct mechanism in the QEP module to capture or report the exact changes to QPOSCNT when a phase error occurs. This is a hardware limitation of the peripheral, as it's designed with the fundamental requirement that A/B signals should not transition simultaneously.

    While the CLB solution you've previously implemented is a viable workaround, I understand your interest in potentially using the original QEP module for a simpler system. However, if precise position tracking during phase errors is critical for your application, I would recommend staying with your planned CLB implementation. This will give you more predictable behavior and the ability to compensate for counting errors through software as you described.

    One suggestion would be to improve the signal isolation and signal integrity on the EQEP signals in hardware to prevent this type of interference from ever occuring.

    If you'd like to explore other potential solutions or have additional questions about either the QEP or CLB implementation, please don't hesitate to ask.

    Best regards,
    Zackary Fleenor