TMS320F28388D: ESC DL Status register reflects connection on Port 1 with only one PHY in design

UPDATE:
I have configured the PHY1_LINKSTATUS signal in software and now I am seeing the correct value in the DL_STATUS ESC register(0x5617).  However, the slave still does not come up on an EtherCAT Bus Scan.

Hi Ben,

I was going to suggest looking into the 'ESC_PHYx_LINKSTATUS' signals, as that's typically the related issue with this behavior. You now have both PH0 and PHY1 LINKSTATUS signals configured? Are they read as HIGH or LOW by the C2000, you can check the GPIO DATA regs for this.

I'll mention that for proper linkstatus detection our C2000 ESC expects an active LOW input signal for this (i.e. LOW means status is good from the PHY). You may need to use GPIO config invert mode or internal pull-up enable / disable depending on your hardware to make this work. 

Ben Farrell said:

However, the slave still does not come up on an EtherCAT Bus Scan.

Are you using TwinCAT? It can be a finicky program sometimes and closing / re-starting it can resolve issues sometimes.

Best,

Kevin

The link_status reflected by the ESC's DL_STATUS register is correct so those signals should be fine.  I have been using TwinCAT and EC engineer and have tried rebooting my machine and these programs.  Neither program is able to detect the node. Based on a Wireshark trace, it doesn't look like the node is responding to the broadcast packets.

Hi Ben,

Could it be hardware related?

Are you using the TI evaluation board (ControlCARD) or your own custom HW? If custom HW can you provide PHY device and any other relevant details?

Best,

Kevin

Hello Kevin,

It is custom HW. I think it is likely FW related as we have other pieces of custom HW with identical EtherCAT circuitry (the only notable difference being all other boards have 2 PHYs while this has 1), and they all function.  Are there any notable configuration changes that need to be made for one PHY operation?

Hi Ben,

I remembered another user having a similar issue with single port EtherCAT. It seems 'ESC_PHY1_LINKSTATUS' signal should still be configured and pulled up (can be done internally with GPIO config) even though you won't be using it. This should tell the C2000 ESC that the port1 is closed. That is what I think worked for them.

Best,

Kevin

Hi Kevin, 

As an update, we are working through HW issues with our board.  After configuring the ESC_PHY1_LINKSTATUS using the internal pullup enable the ESC is now reflected the correct DL_STATUS but we are still unable to scan the slave.  We are getting an increment of the RX Error Counter register in the ESC when the bus scan is run.

Can you provide some insight on what could cause this counter to run?

Hi Ben,

Ben Farrell said:

After configuring the ESC_PHY1_LINKSTATUS using the internal pullup enable the ESC is now reflected the correct DL_STATUS but we are still unable to scan the slave.

What is ESC DL Status (0x0110:0x0111) register value you see now? We only want Port0 to have Link detected, be Open, and with Communication established. All others, including Port1, should be opposite of this.

Checking value of ESC DL Control (0x0100:0x0103) to see if Loop Port X are in Auto / Auto Close mode may be good too.

Best,

Kevin

My ESC DL Status reads 0x5617 indicating that the only open port is 0, all others are closed. I enabled an internal pullup on the PHY1_LINK_STATUS pin and that fixed the Port 1 open issue.  Now we are dealing with an issue where RX Error Counter increments when running a bus scan.  We have validated the MII signals coming from the PHY to the ESC but the ESC believes that the received data is incorrect in some way.  Do you have any other insight as to what this register indicates or what could cause this?

Hi Ben,

Ben Farrell said:

My ESC DL Status reads 0x5617 indicating that the only open port is 0, all others are closed.

This is good. So there's some other issue.

I am currently thinking it is due to Enhanced Link detection which happens through the PHY MI (MDIO / MDC). Below from Beckhoff DS #1.

Disabling Enhanced Link Detection through the EEPROM settings on Port1 may resolve it, but this requires programming the EEPROM first.

Best,

Kevin

I have modified the EEPROM information to only enable enhanced link detection on Port 0 by writing 0x1C to the ESC_CONFIG memory location (0x141).  It seems as though the ESC on the F2838x doesn't support port-by-port enhanced link detection.  It will only allow me to disable enhanced link detection altogether (memory browser shows 0x0C). When enhanced link detection is disabled, the ESC can't detect a link on Port 0.  Are you able to confirm that this ESC supports the functionality that you are describing?

Hi Ben,

Ben Farrell said:

It seems as though the ESC on the F2838x doesn't support port-by-port enhanced link detection.

I assumed it would since they have register bits for each, but maybe you are right. I was hoping you could just disable enhanced link detection for Port1 and keep it enabled on Port0.

Ben Farrell said:

Are you able to confirm that this ESC supports the functionality that you are describing?

I'm consulting with other folks on our design team to understand this issue better and come up with a workaround for single-port EtherCAT implementation.

So far I've learned there's a device bug where the ESC_PHYX_LINKSTATUS (PHY MII_LINK) signal driven to ‘0’ if  not configured. Because of this link1 status is remaining Open in single port configuration, hence the need to configure ESC_PHY1_LINKSTATUS and pull the signal internally or externally. We'll of course need to address this in our documentation.

Best,

Kevin

Hi Ben,

1. Could you check ESC DL Control 0x100 value?

2. Could you measuring setup/hold timing of the data sent from C2000 to PHY, please refer to the figure below. You should measure it as close to the PHY as possible.

Similar measurement should be made on the data sent from PHY to the C2000, but closer to the C2000 and verify it is meeting the C2000 setup/hold timing requirement.

Best Regards,

Zane

Hello Zane, 

The value in ESC DL Control is 0xC001.  Here are the waveforms on the RX MII lines.  There doesn't seem to be anything out of ordinary from our perspective. 

Hi Ben,

Does this issue appear every time after POR? Is appear each board which only have one PHY?

Can you share RX_ERR/RX_DV and RX_CLK wareform?

Best Regards,

Zane

Hi Ben,

I heard from a TI colleague that you were able to find a workaround. That by configuring the other GPIOs on the MCU you are able to make 1-port eCAT work. Is this mean you configured the other Port1 MII IOs even though you do not have / use Port1 PHY? It would be very helpful to understand.

Discussing with our design team they say enhanced link detection per port should be possible as per the bechkoff spec, but needs to be validated by me on the bench.

Best,

Kevin

Hello Kevin,

Yes, we were able to get EtherCAT working.  EtherCAT was the first peripheral to be brought up for this new board so only the GPIOs for the EtherCAT had been declared.  After declaring the GPIO assignments for all other peripherals that are going to be used EtherCAT worked.  We are going to investigate this further to see what (if any) signals were interfering with the EtherCAT communication and will post it to the forum.

Hi Ben,

Thanks for the explanation. That is a strange behavior, with what we know for now at least. Maybe there is a reasonable explanation.

Yes, please let me know if you figure something out. I still plan to do some testing later with our eval board for 1-port eCAT usage and document any requirements / workarounds needed.

Best,

Kevin

Hi Ben,

Ben Farrell said:

We are going to investigate this further to see what (if any) signals were interfering with the EtherCAT communication and will post it to the forum.

Did you have any conclusions from further investigation by chance? Would be of interest to us of course.

Best,

Kevin

Hello Kevin,

After removing the non-EtherCAT GPIO declarations, I was unable to reproduce the issue. I apologize for not being able to provide more insight.

Hi Ben,

That's OK, thanks for getting back to me. If you happen to come across something interesting in the future please let us know.

Best,

Kevin