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

TMS320F28379D: eQEP Gated Index latch issues, and clearing status bits

Wil P.
Expert 1660 points
Part Number: TMS320F28379D


Hello,

I would like some clarity on some issues with the eQEP module. Unfortunately, my experimental setup is remote and not cheap to run so I need to do my best to work through this stuff at my desk.

COEF and CDEF Latched

Can you confirm that the information in this older thread is correct? https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/488827/f28377s----eqep-unable-to-clear-capture-timer-overflow-error-flag

Specifically the post that says:

"Looks like the documentation is incorrect. You need to write "1" COEF bit of QEPSTS to clear it."

If that is indeed correct, it is still not in the latest documentation for the part: "SPRUHM8I". I do not believe that the documentation states that the bit is cleared that way anywhere, nor that it is latched. A note about clearing the bit is there for the UPEVNT flag in the same register, however.

I assume that CDEF would exhibit similar behavior, so can you please confirm that COEF and/or CDEF are indeed latched and need to be cleared with a write of "1". 

Also, there is a typo "QEPCTZ" on page 2176 of the same document.

QEPI Gated to A and B results in wobbling Index Latch

I am using the following relevant settings on a 512 PPR wheel with the index gated to both A and B:

  • Quadrature count mode
  • Synchronous GPIO (no qual)
  • Counting both edges
  • QPOSMAX= 2047
  • PCRM =2
  • IEL= 1
  • Positive rotation

This results in QPOSILAT toggling between 2047 and 2046 many times a second***.  The behavior appears significantly better at higher speeds 6k RPM+ but does not completely go away.  I only want to use the index to reset my counts if a position counter error occurs. My application can afford a few counts of error per revolution, but absolutely can not afford a significant drift if a counter error accumulates over time.  Any QEP counter issue will need to be logged and reported.

The signals all look really clean at the plane of the MCU, and there really is not a noticeable time difference between the edges (certainly less than the 5ns SYSCLK).

Would changing IEL to 3 help? This is my best guess, any advice is appreciated.  I am willing to try many things.  I am considering adding a few ns delay to the index to ensure that it always comes slightly after the first positive edge, but I believe that there has to be a better way to solve this.

EDIT:  My issue seems really similar to this as well: e2e.ti.com/.../tms320f28388d-eqep-module-index-detection

NOTE: I am looking at the values in this thread through buffered values via a CAN HMI, not the debugger.

*** - I currently cannot confirm if other values are latching, but I will add some debug code to check for this during my next test.

  • 0
    TI__Mastermind 18311 points

    Hi Wil,

    Thanks for reaching out about this. I will have to look through our bug tracking to see if this issue was ever officially noted, although since it has been quite a while since the E2E thread you mentioned, I doubt so. Allow me to look into this in further detail

    As an additional debug note, are you making use of any input qualification on your index signal prior to bringing it inside the eQEP peripheral? This software feature should be available as part of the GPIO MUX and may help alleviate issues with the index latching

    Regards,

    Peter

  • 0 in reply to Peter Luong1
    Expert 1660 points

    Hi Peter,

    I am using synchronous mode with no qualification on the GPIO MUX (2nd bullet point in my list).  I can try to add 3 clocks of qualification, but I've verified that the signals are pretty clean (they are isolated after read as 12V differential). It seems that it will just add a needless delay.

  • 0 in reply to Wil P.
    TI__Mastermind 18311 points

    Hi Wil,

    Wil P. said:
    If that is indeed correct, it is still not in the latest documentation for the part: "SPRUHM8I". I do not believe that the documentation states that the bit is cleared that way anywhere, nor that it is latched. A note about clearing the bit is there for the UPEVNT flag in the same register, however.

    Originally, a note was added in the TRM to this register which stated "This bit is cleared by writing a '1' to the corresponding bit in the QCLR register." This note was later removed because there is no corresponding bit, and these bits are read/write so they can be cleared by writing to the bits. 

    It seems this original note was noted incorrectly hence why it was later removed. I can file an amendment to get a more appropriate description added to this register to clarify how to reset the flag.

    Wil P. said:
    Also, there is a typo "QEPCTZ" on page 2176 of the same document.

    You're right, I believe this should be QEPCTL[IEL]. Will work to get that corrected

    Wil P. said:
    I can try to add 3 clocks of qualification, but I've verified that the signals are pretty clean

    Using the QEPCTL[IEL] = 11 Software Index Marker may also be another solution like you mentioned. You are just experiencing wobbling, but no missed index signals, correct? Qualification can help if you are experiencing some missed index signals, but you could test it in this situation to see if you are latching more consistently as well.

    Regards,

    Peter