• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 168 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: T-Fromat interface unexpected state changes

Hang Yang
Expert 4176 points

Part Number: TMS320F28388D

Hi Experts,

My cusotmer is seeing an unexpected state changes in the T-Format encoder interface. This issue only happens on some of the encoders. (specific vendor). 

Blow is a waveform capture of the issue:

421edf4c7c56f2bc95e48f68097e42f0.png

The purple and blue is the TX (to encoder) and RX of the SPI.

The Green is the SPI clock.

The Orange (GPIO1) 1 is the S0 state of the main FSM 

The Yellow(GPIO91) is the Couter1.Match2 which triggers the FSM to flip

image.png

As you can see in the waveform. There is a period that the SPI clock is missing, this is likely because the FSM is in the wrong state (idle). Which means the FSM is triggered from RECEIVE_DATA to IDEL too early. In fact, you may see an unepxected Couter1.match2 signal which triggers the FSM in the period which SPI clock the missing.

In all, the error should be expected match2 signal -> FSM transiti to IDLE earliy -> clock is missing.

The question is that what might cause the unexpected match2 singal?

Note that this only happens on a specific encoder vendor. The same software works fine on other encoder vendors. Even for encoders from this vendor, the error only happens on some of the cycles.

Regards,

Hang

  • 0
    TI__Mastermind 24951 points

    Hi Hang,

    Thanks for your question, I am taking a look at this. Can you provide vendor information?

    Have you confirmed with vendor that their encoder is exactly T-Format compliant?

    Regards,

    Peter

  • 0 in reply to Peter Luong
    TI__Expert 4176 points

    Hi Peter,

    The Vendor is Ruiying. and they claim that their T-Format compliant.

    Neverthless, customer's FPGA solution can handle the encoder of this vendor, we need to make P65 works as well orther wise we lose to the FPGA solution, 

    Even If the encoder is not compliant, we need to indentify the root cause so that we can push this back to the vendor. 

    From the waveform, the cause is in the CLB statemachine instead of encoder response.

    Could you please help looking into the CLB logic and see if we can find the cause of the unexpected state transition?

    Regards,

    Hang

  • 0 in reply to Hang Yang
    TI__Mastermind 24951 points

    Hi Hang,

    Seems this was resolved offline. Please let us know about the issue resolution to see if we need to make any adjustments to the T-Format library or CLB implementation

    Thanks,

    Peter 

  • 0 in reply to Peter Luong
    TI__Expert 4176 points

    HI Peter,

    This issue is result from the SPI clock generation keep running in the background,  even though the state is in "waiting for response". the counter 1 would count this clock from counter0, and counter1 would reach match2 periodically, and generates a match2 pulse. If the timing of the encoder response is perfect, this pulse would cause the state machine to transit from RECEIEVE_DATA to IDLE, right after it transit from WAIT_FOR_START to RECEIVE_DATA, and no RX clock would be generated.

    The solution is simple, we need to hold the clock generator, counter 0, to reset when the state machine is in WAIT_FOR_START.

    Just add an extra condition to the lut0, for example, (original logic) |(!i1&i2)

     

    The issue would affect almost any T-Format encoder. It relates to the interval between the end of the TX transmition and the beginging encoder response.

    I would strongly recommend making some adjustment to the library.

    Regards,

    Hang

  • 0 in reply to Hang Yang
    TI__Mastermind 24951 points

    Hi Hang,

    Thank you very much for looking into and resolving this. I have properly filed this bug fix into our MotorControl SDK backlog items

    Regards,

    Peter