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.

TMS320F28P650DK: Some questions for EtherCAT ESC

Part Number: TMS320F28P650DK
Other Parts Discussed in Thread: LAUNCHXL-F28P65X

Tool/software:

Hi all,

I am studying EtherCAT functionality on the P65x device and have the following questions,

  1. ESCSS_ACCESS_CTRL register bit-10.
    • This bit is configured to allow or not allow memory access through the parallel port, what does this mean and how does it work?
  2. ESCSS_RESET_DEST_CONFIG register bit-0.
    • Is this bit used to enable/disable ESC_PHY_RESETn pin to reset PHY? I ask this question because it seems like ESC_PHY_RESETn pin can reset the PHY, regardless of the setting of this bit.
  3. ESCSS_CONFIG_LOCK register bit-4.
    • This bit is used to allow EtherCAT ports to be connected to the I/O pins. However, regardless of the setting of this bit, the EtherCAT port appears to be connected to the I/O pins.
  4. The bus width for PDI.
    • The Beckhoff ET1100 supports multiple PDIs, and P65x devices support 16-bit ASYNC PDI. Does PDI bus width only affect data access speed? Are there any concerns regarding the PDI bus width (8-bit or 16-bit) ?

Please help me clarify the above questions, thanks for your help.

Luke

  • Hi, Please advise your comments on the questions, thank you.

  • Hi Luke,

    ESCSS_ACCESS_CTRL register bit-10.
    • This bit is configured to allow or not allow memory access through the parallel port, what does this mean and how does it work?

    This feature is not fully documented / supported. There is a parallel port feature to enable a faster alternate path to the DPRAM (but not registers), memory location below.

    ESCSS_RESET_DEST_CONFIG register bit-0.
    • Is this bit used to enable/disable ESC_PHY_RESETn pin to reset PHY? I ask this question because it seems like ESC_PHY_RESETn pin can reset the PHY, regardless of the setting of this bit.

    I believe these are unrelated where ESC_PHY_RESETn will be driven regardless of these settings. I'll let you know if I learn more specifics.

    ESCSS_CONFIG_LOCK register bit-4.
    • This bit is used to allow EtherCAT ports to be connected to the I/O pins. However, regardless of the setting of this bit, the EtherCAT port appears to be connected to the I/O pins.

    I don't think this register bit needs to be exposed to the user. Let me check...

    The bus width for PDI.
    • The Beckhoff ET1100 supports multiple PDIs, and P65x devices support 16-bit ASYNC PDI. Does PDI bus width only affect data access speed? Are there any concerns regarding the PDI bus width (8-bit or 16-bit) ?

    P65x only supports 16-bit ASYNC PDI. This would be the fastest interface when comparing to the other ET1100 options.

    Best,

    Kevin

  • Hi Kevin,

    Thanks for your response. Do you have any updates on question 2 and 3 please?

    Regards,

    Luke

  • Hi Luke,

    I am checking with our design folks. It may take a few days.

    Best,

    Kevin

  • Hi Luke,

    ESCSS_CONFIG_LOCK register bit-4.
    • This bit is used to allow EtherCAT ports to be connected to the I/O pins. However, regardless of the setting of this bit, the EtherCAT port appears to be connected to the I/O pins.

    I don't think this register bit needs to be exposed to the user. Let me check...

    My prior point above is correct, it was intended for some potential future use. For now you should ignore this register bit and we (TI) should make it reserved in a future TRM update.

    ESCSS_RESET_DEST_CONFIG register bit-0.

    I am still working on understanding & confirming this behavior with our design team. I tested our 'f28p65x_cpu1_echoback_solution' example on LAUNCHXL-F28P65X board and saw below behavior while probing GPIO_76_ESC_PHY_RESETN signal.

    Best,

    Kevin

  • Hi Kevin,

    I would like to ask the following questions,

    1. ESCSS_LED_CONFIG Register bit-2, bit-3 and bit-4.

    It seems that the LEDs work, regardless of the settings of those bits of this register. Do these bits really work?

    2. ESCSS_RESET_DEST_CONFIG Register bit-0, bit-1, bit-2 and bit-7.

    Do you have the update about bit-0 from design team? Does this bit work?
    I don't really understand when and how should I use bit-1, bit-2 and bit-7 of this register, how can I test and check whether or not these bits work?

    Please advise your comments, thanks for your help.

    Regards,

    Luke

  • Hello Kevin,

    Please advise your comments on the questions of previous post, thanks for your help.

    Regards,

    Luke

  • Hi Luke,

    ESCSS_LED_CONFIG Register bit-2, bit-3 and bit-4.

    Checking with our design folks on this one.

    ESCSS_RESET_DEST_CONFIG Register bit-0, bit-1, bit-2 and bit-7.

    Do you have the update about bit-0 from design team? Does this bit work?
    I don't really understand when and how should I use bit-1, bit-2 and bit-7 of this register, how can I test and check whether or not these bits work?

    These bits were originally intended to be separate from Device Reset to support Reset Isolation between ESC IP and the CPU when a RESET_OUT from ESC occurs. It's still unclear to me how this reset isolation is designed and how these register bits affect it.

    Best,

    Kevin

  • Hi Kevin,

    Please keep checking with design team, keep me posted when you have any update about the questions.
    Thanks for your great support.

    Regards,

    Luke

  • Hi Luke,

    ESCSS_LED_CONFIG Register bit-2, bit-3 and bit-4.

    Checking with our design folks on this one.

    These register bits seem to have no impact. It's our understanding is that once the GPIO is configured to be used as the ECAT_LED_RUN pin, it will configure the IO pad to output itself.

    Still spending time to understand and test ESCSS_RESET_DEST_CONFIG functionality.

    We need to take action to update many of the ESCSS registers & descriptions, many should be hidden / reserved as they have no impact.

    Best,

    Kevin