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.

TMS320F280025C: EQEP Datasheet Clarification/Inconsistency

Part Number: TMS320F280025C


I'm trying to plumb some signals into the qep on a 0025.  Plan is to use the input x bar and the epwn xbar to get the signals to the peripheral, but I've noticed a discrepancy in the TRM.

spruin7b page 2135 describes the source selection options for the qep.  Some of these options include PWMXBAR.1 - PWMXBAR.7.

However in all the xbar docs, the EPWM XBars are labeled TRIPx.  There are also 8 EPWM XBar channels while only 7 appear to connect to the qep.

Am I correct in assuming this was an oversight and the register descriptions need to be updated to match the naming of EPWM Xbar channels?  What is the mapping?  Since one isn't connected I can't assume a straight 1:1 in order mapping.

Thanks!

Trey

  • Hi Trey, 

    I am verifying this information with our EPWM XBAR experts. Per the datasheet, only EPWMXBAR 1-7 can be used as inputs into the EQEP (see Table 20-1 in the TRM) since there are not enough to configure an additional one within the 16-bit register. There are eight total EPWMXBAR, denoted as EPWMXBAR 1-8. Other peripherals, for example, FSI, have access to all eight EPWMXBARs. 

    There should be a 1-1 matching for TRIPx to EPWMXBARy, not including EPWMXBAR8. I will let you know what the EPWM experts say, but I would image that TRIP4 corresponds with EPWMXBAR1, TRIP5 corresponds to EPWMXBAR2, etc.

    Regards,

    Peter

  • Peter,

    Appreciate you checking on this for me.  Will standby for your response.

    The underlying issue here seems like a common one for C2k and probably other BUs across TI.  I personally have ran into this issue several times.  Peripherals are owned by different folks and the TRM sections get reviewed separately.  I'm sure also most of the register description stuff comes from design.  In the end because there are so many "sources" coming together, this creates a big potential for these boo boos in the documentation.

    How TI fixes this? I'm not sure, but I do know errors like this detract from customer experience.

    Best,

    Trey

  • Hi Trey,

    I just confirmed that this bug has already been filed and should be updated in the next release of the TRM. 

    The EPWMXBARx to TRIPx matching is as follows: 

    EPWMXBAR1 = TRIP4

    EPWMXBAR2 = TRIP5

    EPWMXBAR3 = TRIP7

    EPWMXBAR4 = TRIP8

    EPWMXBAR5 = TRIP9

    EPWMXBAR6 = TRIP10

    EPWMXBAR7 = TRIP11

    EPWMXBAR8 = TRIP12

    So on EQEP, you simply do not have access to TRIP12 from the EPWM XBAR. 

    As for in terms of how we are planning to alleviate this, we actually have implemented universal speccing which populates all of these kinds of TRM tables and information from a single source so that we can mitigate issues like this. Please let me know if you have any additional questions!


    Regards,

    Peter 

  • Peter,

    Thanks for getting back to me with this information.

    Also great to hear strides are being made internally to prevent these mismatches in the docs!  Keep up the good work C2k team!!

    Best,

    Trey