AM6442: IND-COMMS-SDK EtherCAT Beckhoff Slave Example -- am64x IEP configuration

Hi Jakob,

If you are not planning to use the latch0/1 and sync0/1 pins, then it is fine to remove it from the sysconfig.

You can also map the sync signals to one of 4 Time Sync Router SYNCx_OUT pins: 

Regards,

Aaron

Hi Aaron,
by not using them you mean, I do not need them on a GPIO Pin right? 
The PRUICSS Ethercat Slave controller firmware requires them for the distributed clock mechanism, right? 

How do I configure that correctly? 

Kind regards,

Jakob

Hi Jakob,
Sorry for the late response. Please give me some time to look into this.

Jakob Roll said:

The PRUICSS Ethercat Slave controller firmware requires them for the distributed clock mechanism, right? 

• Yes, you are right.

Jakob Roll said:

How do I configure that correctly? 

• You mean you want to map the sync signals to the TSR SYNCx_OUT pins instead of the PRG0_IEP0_EDC_SYNC_OUTx pin? Please give me some time to look into this. I will get back to you by Wednesday EOD.

Regards,

Aaron

Hi Aaron,

At the moment I do not need the signals on any GPIO Pin to use the signal "outside" of the am64x. I am wondering, whether I need to map the signals to any pin in order for the PRUICSS to use them or if this is configured in another way.  

In the ethercat_slave_beckhoff_ssc_demo code in tiescsoc.c there is the following code:

void tiesc_socEvmInit()
{
    const PRUICSS_HwAttrs *pruicssHwAttrs;
    uint32_t inEventLatch0, inEventLatch1, outEventLatch0, outEventLatch1;
    
    ...
    ...
    
    /* TimeSync Router configuration for latch pins */
    if(pruicssHwAttrs->instance == 0)
    {
        inEventLatch0 = CSLR_TIMESYNC_EVENT_INTROUTER0_IN_PINFUNCTION_PRG0_IEP0_EDC_LATCH_IN0IN_PRG0_IEP0_EDC_LATCH_IN0_0;
        inEventLatch1 = CSLR_TIMESYNC_EVENT_INTROUTER0_IN_PINFUNCTION_PRG0_IEP0_EDC_LATCH_IN1IN_PRG0_IEP0_EDC_LATCH_IN1_0;
        outEventLatch0 = TIMESYNC_EVENT_INTROUTER0_MUXCNTL_8;
        outEventLatch1 = TIMESYNC_EVENT_INTROUTER0_MUXCNTL_9;
    }
    else
    {
        inEventLatch0 = CSLR_TIMESYNC_EVENT_INTROUTER0_IN_PINFUNCTION_PRG1_IEP0_EDC_LATCH_IN0IN_PRG1_IEP0_EDC_LATCH_IN0_0;
        inEventLatch1 = CSLR_TIMESYNC_EVENT_INTROUTER0_IN_PINFUNCTION_PRG1_IEP0_EDC_LATCH_IN1IN_PRG1_IEP0_EDC_LATCH_IN1_0;
        outEventLatch0 = TIMESYNC_EVENT_INTROUTER0_MUXCNTL_12;
        outEventLatch1 = TIMESYNC_EVENT_INTROUTER0_MUXCNTL_13;
    }

    HW_WR_REG32((CSL_TIMESYNC_EVENT_INTROUTER0_CFG_BASE + outEventLatch0), (inEventLatch0 | 0x10000)); // 0x10000 for enabling interrupt see userguide 10.3.2.3.1.2.1
    HW_WR_REG32((CSL_TIMESYNC_EVENT_INTROUTER0_CFG_BASE + outEventLatch1), (inEventLatch1 | 0x10000));
}

Does this code require the signals to be mapped to GPIO Pins? 

The question how to configure the IEP module or PRU in general means, what steps are needed to provide the required signals to the PRUICSS Firmware?

Regards,
Jakob

Hi Jakob,

Jakob Roll said:

I am wondering, whether I need to map the signals to any pin in order for the PRUICSS to use them or if this is configured in another way.  

• Yes, you need to map signals to specific pins for the PRUICSS to use them for EtherCAT communication. The EtherCAT driver will use the mapped pins.

Jakob Roll said:

The question how to configure the IEP module or PRU in general means, what steps are needed to provide the required signals to the PRUICSS Firmware?

• I will look into this and get back to you by Monday.

Regards,

Aaron

Hi Jakob,

Jakob Roll said:

At the moment I do not need the signals on any GPIO Pin to use the signal "outside" of the am64x.

If you don't intend to use the SYNC/LATCH signals outside of the AM64x I don't think you need to map them onto any pins.

Jakob Roll said:

The PRUICSS Ethercat Slave controller firmware requires them for the distributed clock mechanism, right? 

I'm not sure what you mean by that. The ESC firmware is perfectly happy without these signals. IMHO the question is what you want to do with DC within the AM64x. Just having some code run on the R5f via a Sync0/1 interrupts doesn't require these signals. If you want to route these signals via AM64x internal time sync router you don't need them externally either.

Please note I'm not TI, so they might have other advice for you.

Regards,

Dominic

Hi Dominic,
thanks for your reply. At the moment all I want is to run the industrial communications example with the Beckhoff EtherCAT stack on the PHYTEC board.
AM64x INDUSTRIAL COMMUNICATIONS SDK: EtherCAT SubDevice Beckhoff SSC Demo

Using TwinCAT or the EtherCAT Conformance tool, the device is not recognized as an EtherCAT sub device. Using wireshark I can see, that after the broadcast to scan for subdevices, nothing happens on the ESC side, i.e. no answer is sent. 

Therefore I am trying to find the root cause to that. Changes I had to make to the example are the used PRU (PRU-ICSSG0 instead of ICSSG1) and remove the sync and latch signals from the Pins. This is why I am concerned about that signals.

Kind regards, 
Jakob

Hello Jakob,

at that level this has (almost certainly, as in 99.9%...) nothing to do with the Sync and Latch signals.

Which Phytec board are you using? The phyBOARD-AM64x?

What software are you running on the AM64x? Ind. Comms / MCU+ SDK standalone, without Linux? Or are you trying to run the EtherCAT subdevice alongside Linux?

If you're running the MCU+ SDK standalone on the phyBOARD-AM64x:

The phyBOARD uses the AM64's EXT_REFCLK1 pin as CLKOUT0 to output a 25 MHz reference clock for the ICSSG ethernet PHYs. If you're using a stock Ind. Comms SDK from TI's website, that's not being enabled yet. I've been doing this manually, e.g. like this:

    /* configure EXT_REFCLK1 (A19) as CLKOUT0, output */
    *(volatile uint32_t*) 0x000f4274 = 0x10005;

    /* enable CLKOUT0 @25 MHz */
    *(volatile uint32_t*) 0x43008010 = 0x11;

I haven't used the phyBOARD as a sub-device yet, so unfortunately I don't know if that's all that is required, or if you're going to face further obstacles.

Regards,

Dominic

Hi Dominic,
yes its the phyBOARD-am64x and yes MCU+ SDK standalone.
I configured the reference clock. I checked via the ESC-MDIO API that both PHYs are alive and show Link Up when connected to the PC. I also changed the PHYs to use MII configuration. 
Therefore I think the PHYs should not be the problem. But I also don't really know where to look next, if the Sync and Latch Signals are not the problem.

Regards,
Jakob

Hi Jakob,

Jakob Roll said:

via the ESC-MDIO API that both PHYs are alive and show Link Up when connected to the PC

IIRC the ESC firmware doesn't use MDIO to determine the link state, but relies on the RXLINK pins by default (that is change-able via configuration). I believe could check the ICSSG's MDIO_LINK_REG to determine if the ICSSG detected the link.

If there's a link, you could verify the Pin Mux at the SoC level and at the PRU level to verify that all MII pins are configured correctly.

If all the pins are correctly configured you could look at the MII_G_RT_RX_STAT_* registers. IIRC you should see received frames counting up there.

We've brought the TI ESC slave up on a couple of custom boards, but there's always subtle details that can go wrong. Maybe someone from TI has additional suggestions for you.

Regards,

Dominic

Hi Dominic, 

I checked the registers of the ESC AM64x INDUSTRIAL COMMUNICATIONS SDK: TI EtherCAT SubDevice Controller Register List.
When I connect the ESC to the PC, the ESC DL Status register changes to "Port 0 link up" and "port 0 connection established".

Also the frame counter register gets incremented, when I send frames from the PC, at the same time, the error counter registers stay at 0.

Do you know what else could go wrong, maybe on the TX side?  Because the ESC does not answer to the ECAT Link discovery of the conformance tool.

Thank you very much for your help so far.

Kind regards,
Jakob

Hi Jakob,

Jakob Roll said:

Changes I had to make to the example are the used PRU (PRU-ICSSG0 instead of ICSSG1)

• Can you confirm if you are trying to use the ICSSG0 instance ?
• If yes, then we have a dedicated example for the same in latest Industrial Communications SDK - 09.02 : EtherCAT SubDevice Beckhoff SSC Demo: ICSSG0 Instance

In case of ICSSG0 instance, you will be needing an add-on board and make sure that the PHY reset sequence and the ETHPHY initialization is done with respect to the corresponding add-on board along with the sysconfig changes. You can look into the above mentioned example for reference.  

Regards,

Aaron

Hi Aaron, 
yes I am usin ICSSG0, but since I am not using the TI-EVM but the phyboard am64x, I do not need the workaround with an additional board.
To be sure I migrated to the latest version of ind-comms (V09.02.00.00.08)
I get the same behaviour as before. 

As mentioned earlier, the ESC does receive ECAT frames when connected to the PC (Conformance tool, subdevice scan). Thus there is no problem on the PHY-Configuration. At least on the RX-side.

What needs to happen, such that the ESC answers to the broadcast? 

Kind regards,
Jakob

I believe you are using the example running on r5fss1-0. Do make sure that the sysconfig changes are initialized based on the board.

Jakob Roll said:

As mentioned earlier, the ESC does receive ECAT frames when connected to the PC (Conformance tool, subdevice scan).

• Can you share the wireshark logs for the same ?

Regards,

Aaron

Hi Aaron, 
yes for the latest version of the ind-comms it is on r5fss-1-0. Since I use only one core, I will change that to r5fss-0-0.
Here is a screenshot of a log. Unfortunaltely you can't see much, since the ESC does not answer, The first three frames are "Scan for available devices" and the remaining frames are "Scan for slaves", initiated with the EtherCAT Conformance Tool. When I send these frames and check the register 0x0E00 (Port 0 Frame counter) of the ESC, it gets incremented. Therefore the ESC sees those frames. I do not know how to find out, why it does not send an answer. The register 0x030C (ECAT Processing Unit Error Counter) does not increment when the ESC receives the frames, neither does the RX Error Counter (0x0300)

Regards,
Jakob

Hi Jakob,

Thanks for the confirmation.

Would it be possible to share the EtherCAT sysconfig snapshot to confirm if the Tx pins of PRU0/1 are connected to MII0/MII1 ?

Regards,

Aaron 

Hi Aaron,
sure, here is a screenshot of the MII Signals,
I also checked, that the signals are routed to the PHYs correctly on the schematics of the board.


Regards,
Jakob

Thanks Jakob.

This seems to be aligned. Can you provide the ICSS Memory Dump (ESC Registers and MDIO registers in particular) ?

Hi Aaron,
of course. I appended the dumps. 
The CPU Error counter is at 3, since as soon as I connect the Ethernet Cable to the host, three packets of the EAPOL protocol are sent. (This is a setting based on company settings and I can't disable it). If I send EtherCAT frames, the RX counter goes up, but the CPU error counter stays the same.
The MDIO register values are from PRU_ICSSG0_PR1_MDIO_V1P7_MDIO address with the corresponding offsets.

The phy addresses are 1 and 2. Phy address 1 is port 0.

MDIO_VERSION_REG: 0x70107
MDIO_CONTROL_REG: 0x410000FF
MDIO_ALIVE_REG: 0x6
MDIO_LINK_REG: 0x2
MDIO_LINK_INT_RAW_REG: 0x0
MDIO_LINK_INT_MASKED_REG: 0x0
MDIO_LINK_INT_MASK_SET_REG: 0x0
MDIO_LINK_INT_MASK_CLEAR_REG: 0x0
MDIO_USER_INT_RAW_REG: 0x1
MDIO_USER_INT_MASKED_REG: 0x0
MDIO_USER_INT_MASK_SET_REG: 0x0
MDIO_USER_INT_MASK_CLEAR_REG: 0x0
MDIO_MANUAL_IF_REG: 0x0
MDIO_POLL_REG: 0x0
MDIO_POLL_EN_REG: 0xFFFFFFFF
MDIO_CLAUS45_REG: 0x0
MDIO_USER_ADDR0_REG: 0x0
MDIO_USER_ADDR1_REG: 0x0

0x0: 0x90
0x1: 0x6
0x2: 0x14
0x3: 0x5
0x4: 0x8
0x5: 0x8
0x6: 0x3b
0x7: 0xf
0x8: 0x8c
0x9: 0x0
0xa: 0x0
0xb: 0x0
0xc: 0x0
0xd: 0x0
0xe: 0x0
0xf: 0x0
0x10: 0x0
0x11: 0x0
0x12: 0x1
0x13: 0x0

0x100: 0x1
0x101: 0x0
0x102: 0x0
0x103: 0x0

0x108: 0x0
0x109: 0x0

0x110: 0x21
0x111: 0x5d

0x120: 0x0
0x121: 0x0

0x130: 0x1
0x131: 0x0

0x134: 0x0

0x140: 0x80
0x141: 0xc

0x150: 0xe0
0x151: 0x0
0x152: 0x0
0x153: 0x0

0x200: 0x0
0x201: 0x0

0x204: 0x0
0x205: 0x0
0x206: 0xff
0x207: 0x0

0x210: 0xc
0x211: 0x0

0x220: 0x40
0x221: 0x0
0x222: 0x0
0x223: 0x0

0x300: 0x0
0x301: 0x0
0x302: 0x0
0x303: 0x0
0x304: 0x0
0x305: 0x0
0x306: 0x0
0x307: 0x0
0x308: 0x0
0x309: 0x0
0x30a: 0x0
0x30b: 0x0
0x30c: 0x3
0x30d: 0x0

0x310: 0x1
0x311: 0x0
0x312: 0x0
0x313: 0x0

0x400: 0xc2
0x401: 0x9

0x410: 0xe8
0x411: 0x3

0x420: 0xe8
0x421: 0x3

0x440: 0x0
0x441: 0x0
0x442: 0x0
0x443: 0x2

0x500: 0x0
0x501: 0x0
0x502: 0x60
0x503: 0x0
0x504: 0x0
0x505: 0x0
0x506: 0x0
0x507: 0x0
0x508: 0x0
0x509: 0x0
0x50a: 0x0
0x50b: 0x0
0x50c: 0x0
0x50d: 0x0
0x50e: 0x0
0x50f: 0x0
0x510: 0x0
0x511: 0x0
0x512: 0x0
0x513: 0x0
0x514: 0x0
0x515: 0x0

0x600: 0x0
0x601: 0x0
0x602: 0x0
0x603: 0x0
0x604: 0x0
0x605: 0x0
0x606: 0x0
0x607: 0x0
0x608: 0x0
0x609: 0x0
0x60a: 0x0
0x60b: 0x0
0x60c: 0x0
0x60d: 0x0
0x60e: 0x0
0x60f: 0x0
0x610: 0x0
0x611: 0x0
0x612: 0x0
0x613: 0x0
0x614: 0x0
0x615: 0x0
0x616: 0x0
0x617: 0x0
0x618: 0x0
0x619: 0x0
0x61a: 0x0
0x61b: 0x0
0x61c: 0x0
0x61d: 0x0
0x61e: 0x0
0x61f: 0x0
0x620: 0x0
0x621: 0x0
0x622: 0x0
0x623: 0x0
0x624: 0x0
0x625: 0x0
0x626: 0x0
0x627: 0x0
0x628: 0x0
0x629: 0x0
0x62a: 0x0
0x62b: 0x0
0x62c: 0x0
0x62d: 0x0
0x62e: 0x0
0x62f: 0x0
0x630: 0x0
0x631: 0x0
0x632: 0x0
0x633: 0x0
0x634: 0x0
0x635: 0x0
0x636: 0x0
0x637: 0x0
0x638: 0x0
0x639: 0x0
0x63a: 0x0
0x63b: 0x0
0x63c: 0x0
0x63d: 0x0
0x63e: 0x0
0x63f: 0x0
0x640: 0x0
0x641: 0x0
0x642: 0x0
0x643: 0x0
0x644: 0x0
0x645: 0x0
0x646: 0x0
0x647: 0x0
0x648: 0x0
0x649: 0x0
0x64a: 0x0
0x64b: 0x0
0x64c: 0x0
0x64d: 0x0
0x64e: 0x0
0x64f: 0x0
0x650: 0x0
0x651: 0x0
0x652: 0x0
0x653: 0x0
0x654: 0x0
0x655: 0x0
0x656: 0x0
0x657: 0x0
0x658: 0x0
0x659: 0x0
0x65a: 0x0
0x65b: 0x0
0x65c: 0x0
0x65d: 0x0
0x65e: 0x0
0x65f: 0x0
0x660: 0x0
0x661: 0x0
0x662: 0x0
0x663: 0x0
0x664: 0x0
0x665: 0x0
0x666: 0x0
0x667: 0x0
0x668: 0x0
0x669: 0x0
0x66a: 0x0
0x66b: 0x0
0x66c: 0x0
0x66d: 0x0
0x66e: 0x0
0x66f: 0x0
0x670: 0x0
0x671: 0x0
0x672: 0x0
0x673: 0x0
0x674: 0x0
0x675: 0x0
0x676: 0x0
0x677: 0x0
0x678: 0x0
0x679: 0x0
0x67a: 0x0
0x67b: 0x0
0x67c: 0x0
0x67d: 0x0
0x67e: 0x0
0x67f: 0x0

0x800: 0x0
0x801: 0x0
0x802: 0x0
0x803: 0x0
0x804: 0x0
0x805: 0x0
0x806: 0x0
0x807: 0x1
0x808: 0x0
0x809: 0x0
0x80a: 0x0
0x80b: 0x0
0x80c: 0x0
0x80d: 0x0
0x80e: 0x0
0x80f: 0x1
0x810: 0x0
0x811: 0x0
0x812: 0x0
0x813: 0x0
0x814: 0x0
0x815: 0x0
0x816: 0x0
0x817: 0x1
0x818: 0x0
0x819: 0x0
0x81a: 0x0
0x81b: 0x0
0x81c: 0x0
0x81d: 0x0
0x81e: 0x0
0x81f: 0x1
0x820: 0x0
0x821: 0x0
0x822: 0x0
0x823: 0x0
0x824: 0x0
0x825: 0x0
0x826: 0x0
0x827: 0x1
0x828: 0x0
0x829: 0x0
0x82a: 0x0
0x82b: 0x0
0x82c: 0x0
0x82d: 0x0
0x82e: 0x0
0x82f: 0x1
0x830: 0x0
0x831: 0x0
0x832: 0x0
0x833: 0x0
0x834: 0x0
0x835: 0x0
0x836: 0x0
0x837: 0x1
0x838: 0x0
0x839: 0x0
0x83a: 0x0
0x83b: 0x0
0x83c: 0x0
0x83d: 0x0
0x83e: 0x0
0x83f: 0x1

0x900: 0x0
0x901: 0x0
0x902: 0x0
0x903: 0x0
0x904: 0x0
0x905: 0x0
0x906: 0x0
0x907: 0x0
0x908: 0x0
0x909: 0x0
0x90a: 0x0
0x90b: 0x0
0x90c: 0x0
0x90d: 0x0
0x90e: 0x0
0x90f: 0x0
0x910: 0x0
0x911: 0x0
0x912: 0x0
0x913: 0x0
0x914: 0x0
0x915: 0x0
0x916: 0x0
0x917: 0x0
0x918: 0x0
0x919: 0x0
0x91a: 0x0
0x91b: 0x0
0x91c: 0x0
0x91d: 0x0
0x91e: 0x0
0x91f: 0x0
0x920: 0x0
0x921: 0x0
0x922: 0x0
0x923: 0x0
0x924: 0x0
0x925: 0x0
0x926: 0x0
0x927: 0x0
0x928: 0x0
0x929: 0x0
0x92a: 0x0
0x92b: 0x0
0x92c: 0x0
0x92d: 0x0
0x92e: 0x0
0x92f: 0x0
0x930: 0x0
0x931: 0x10
0x932: 0x0
0x933: 0x0
0x934: 0x0
0x935: 0xc

0x980: 0x0
0x981: 0x0
0x982: 0xe8
0x983: 0x3
0x984: 0x0

0x98e: 0x0
0x98f: 0x0
0x990: 0x0
0x991: 0x0
0x992: 0x0
0x993: 0x0
0x994: 0x0
0x995: 0x0
0x996: 0x0
0x997: 0x0
0x998: 0x0
0x999: 0x0
0x99a: 0x0
0x99b: 0x0
0x99c: 0x0
0x99d: 0x0
0x99e: 0x0
0x99f: 0x0
0x9a0: 0x0
0x9a1: 0x0
0x9a2: 0x0
0x9a3: 0x0
0x9a4: 0x0
0x9a5: 0x0
0x9a6: 0x0
0x9a7: 0x0
0x9a8: 0x0
0x9a9: 0x0

0x9ae: 0x0
0x9af: 0x0
0x9b0: 0x0
0x9b1: 0x0
0x9b2: 0x0
0x9b3: 0x0
0x9b4: 0x0
0x9b5: 0x0
0x9b6: 0x0
0x9b7: 0x0
0x9b8: 0x0
0x9b9: 0x0
0x9ba: 0x0
0x9bb: 0x0
0x9bc: 0x0
0x9bd: 0x0
0x9be: 0x0
0x9bf: 0x0
0x9c0: 0x0
0x9c1: 0x0
0x9c2: 0x0
0x9c3: 0x0
0x9c4: 0x0
0x9c5: 0x0
0x9c6: 0x0
0x9c7: 0x0
0x9c8: 0x0
0x9c9: 0x0
0x9ca: 0x0
0x9cb: 0x0
0x9cc: 0x0
0x9cd: 0x0
0x9ce: 0x0
0x9cf: 0x0

0x9f0: 0x0
0x9f1: 0x0
0x9f2: 0x0
0x9f3: 0x0

0x9f8: 0x0
0x9f9: 0x0
0x9fa: 0x0
0x9fb: 0x0
0x9fc: 0x0
0x9fd: 0x0
0x9fe: 0x0
0x9ff: 0x0

0xe00: 0x3
0xe01: 0x0
0xe02: 0x0
0xe03: 0x0
0xe04: 0x0
0xe05: 0x0
0xe06: 0x0
0xe07: 0x0
0xe08: 0x1
0xe09: 0x2
0xe0a: 0x80

0xe0c: 0x6
0xe0d: 0x0
0xe0e: 0x0
0xe0f: 0x0
0xe10: 0x48
0xe11: 0x0
0xe12: 0x48
0xe13: 0x0
0xe14: 0x0
0xe15: 0x0
0xe16: 0x0
0xe17: 0x0
0xe18: 0x1
0xe19: 0x2
0xe1a: 0x0
0xe1b: 0x20
0xe1c: 0xff
0xe1d: 0x0
0xe1e: 0x0
0xe1f: 0x0
0xe20: 0x70
0xe21: 0x17
0xe22: 0xfc
0xe23: 0x6
0xe24: 0x0
0xe25: 0x0
0xe26: 0x0
0xe27: 0x0
0xe28: 0x0
0xe29: 0x0
0xe2a: 0x0
0xe2b: 0x0
0xe2c: 0x0
0xe2d: 0x0
0xe2e: 0x0
0xe2f: 0x0
0xe30: 0x0
0xe31: 0x0
0xe32: 0x0
0xe33: 0x0
0xe34: 0x0
0xe35: 0x0
0xe36: 0x1
0xe37: 0x0
0xe38: 0x0
0xe39: 0x0
0xe3a: 0x0
0xe3b: 0x0
0xe3c: 0x0
0xe3d: 0x0
0xe3e: 0x0
0xe3f: 0x0
0xe40: 0x0
0xe41: 0x0
0xe42: 0x0
0xe43: 0x0
0xe44: 0x0
0xe45: 0x0
0xe46: 0x0
0xe47: 0x0
0xe48: 0x0
0xe49: 0x0
0xe4a: 0x0
0xe4b: 0x0
0xe4c: 0x0
0xe4d: 0x0
0xe4e: 0x0
0xe4f: 0x0
0xe50: 0x0
0xe51: 0x0
0xe52: 0x0
0xe53: 0x0
0xe54: 0x0
0xe55: 0x0
0xe56: 0x0
0xe57: 0x0
0xe58: 0x0
0xe59: 0x0
0xe5a: 0x0
0xe5b: 0x0
0xe5c: 0x0
0xe5d: 0x0
0xe5e: 0x0
0xe5f: 0x0
0xe60: 0x0
0xe61: 0x0
0xe62: 0x0
0xe63: 0x0
0xe64: 0x0
0xe65: 0x0
0xe66: 0x0
0xe67: 0x0
0xe68: 0x0
0xe69: 0x0
0xe6a: 0x0
0xe6b: 0x0
0xe6c: 0x0
0xe6d: 0x0
0xe6e: 0x0
0xe6f: 0x0
0xe70: 0x0
0xe71: 0x0
0xe72: 0x0
0xe73: 0x0
0xe74: 0x0
0xe75: 0x0
0xe76: 0x0
0xe77: 0x0
0xe78: 0x0
0xe79: 0x0
0xe7a: 0x0
0xe7b: 0x0
0xe7c: 0x0
0xe7d: 0x0
0xe7e: 0x0
0xe7f: 0x0
0xe80: 0x0
0xe81: 0x0
0xe82: 0x0
0xe83: 0x0
0xe84: 0x0
0xe85: 0x0
0xe86: 0x0
0xe87: 0x0
0xe88: 0x0
0xe89: 0x0
0xe8a: 0x0
0xe8b: 0x0
0xe8c: 0x0
0xe8d: 0x0
0xe8e: 0x0
0xe8f: 0x0
0xe90: 0x0
0xe91: 0x0
0xe92: 0x0
0xe93: 0x0
0xe94: 0x0
0xe95: 0x0
0xe96: 0x0
0xe97: 0x0
0xe98: 0x0
0xe99: 0x0
0xe9a: 0x0
0xe9b: 0x0
0xe9c: 0x0
0xe9d: 0x0
0xe9e: 0x0
0xe9f: 0x0
0xea0: 0x0
0xea1: 0x0
0xea2: 0x0
0xea3: 0x0
0xea4: 0x0
0xea5: 0x0
0xea6: 0x0
0xea7: 0x0
0xea8: 0x0
0xea9: 0x0
0xeaa: 0x0
0xeab: 0x0
0xeac: 0x0
0xead: 0x0
0xeae: 0x0
0xeaf: 0x0
0xeb0: 0x0
0xeb1: 0x0
0xeb2: 0x0
0xeb3: 0x0
0xeb4: 0x0
0xeb5: 0x0
0xeb6: 0x0
0xeb7: 0x0
0xeb8: 0x0
0xeb9: 0x0
0xeba: 0x0
0xebb: 0x0
0xebc: 0x0
0xebd: 0x0
0xebe: 0x0
0xebf: 0x0
0xec0: 0x0
0xec1: 0x0
0xec2: 0x0
0xec3: 0x0
0xec4: 0x0
0xec5: 0x0
0xec6: 0x0
0xec7: 0x0
0xec8: 0x0
0xec9: 0x0
0xeca: 0x0
0xecb: 0x0
0xecc: 0x0
0xecd: 0x0
0xece: 0x0

Thanks Jakob. I'll analyze this and get back to you.

Regards,

Aaron

Hi Aaron,

I also found, that the ESC register for DL Status (0x110) shows "link up" and "connection established" for Port 1, even though it is connected to port 0.
This can be confirmed, by looking at the Port 0 frame counter register that gets incremented when it is connected to the host PC.

This is only the case in the new release 09_02_00_08. It shows "link up" and "connection established" correctly in the release 09_01_00_03.

The register dump in my last post, shows this behaviour as well. port 0 frame counter is at 3 (0xE00) and it shows port 1 is connected (0x110)


Regards,
Jakob

Thank you for this observation. I'll check this internally and get back to you.

Regards,

Aaron

Hi Jakob,

Jakob Roll said:

I also found, that the ESC register for DL Status (0x110) shows "link up" and "connection established" for Port 1, even though it is connected to port 0.
This can be confirmed, by looking at the Port 0 frame counter register that gets incremented when it is connected to the host PC.

• I compared the values with our working example and I see that in our example, we have bit9 of ESC DL Status set, implying "Communication established over port0".
• Also, bit8 is reset, implying loop on port 0 is opened and bit4 is set, implying Physical Link on Port0 detected.
• Can you confirm is the PHY address is swapped during configuration?

Regards,

Aaron