TMDSICE3359: EtherNet/IP questions

Hi Stefan,

I will try to set up my platform to see if these issues you observed can be reproduced.

Have you tried to disable ACD or define _INCLUDE_ACD_SUPPORT and then re-build NDK when ACD is enabled?

To disable PTP feature, you may call  TimeSync_drvDisable(icssEipHandle->timeSyncHandle); and remove the symbol 'PTP_TESTING' defined in CCS project.

You should be able to add a reset or startup function like below to activate the DMTimer4, please refer to http://rtsc.eclipse.org/docs-tip/Using_xdc.runtime_Startup/TI

var Startup = xdc.useModule('xdc.runtime.Startup');
Startup.resetFxn = '&activateDMTimer4';

Regards,

Garrett

Hi Garrett,

Thank you so much for your answer.

I haven't tried ACD or PTP disable yet.

I will have a look at it.

Regards,

Stefan

Stefan,

I can always ping the EIP device from a remote PC connecting to a router which has an internal DHCP server to assign IP address. I ping the device and list identity using EIPTool from Molex after booting for 20 minutes. Do you have other devices connected to the DHCP server? Does the issue only happen with DHCP enabled?

I did see slow response of list identify request and sometimes delay to 1.5s as you said, will discuss with our team and then update you.

I tried to pull and plug the ethernet cable a couple of times without problem too. Can you please try to use a static IP address instead of DHCP too?

Regards,

Garrett

Hi Garrett,

ICMP is not the problem. Only TCP seems to stop working. UDP is still working too all the time. In the net there is no other device. Just my PC as DHCP server.

So if I pull and plug the only cable a few times in a short time the Ethernet/IP stack seems to freeze.

I will do the tests with a static IP...

Thank you and best regards,

Stefan

Hi Garrett,

I forgot to mention that I'm compiling the project as debug

But i've done some more testing with strange results:

• DHCP disabled --> the TCP problem still exist
• DHCP enabled with lease time 1day --> after exactly 6hours the IP-stack deregister and register the IP
• DHCP enabled with lease time 120s --> after exactly 17minutes the IP-stack deregister and register the IP

ACD was enabled the whole time. This will be the next tests...

I'm hoping that you can help me a little bit with this issues as I can't figure out what is calling SPIpNet() with CFGOP_REMOVE

Thank you in advance and best regards,

Stefan

Hi Stefan,

>>ICMP is not the problem. Only TCP seems to stop working.

I overlooked this. Yes, I am seeing TCP RST/ACK as well, will investigate this and let you know...

Regards,
Garrett

Hi Garrett,

do you have some informations? Could you localize the problem?

Regards,

Stefan

Stefan,

ACD appears to be irrelevant to the TCP connection failure. I have escalated the issue internally, will let you know if any progress.

Regards,
Garrett

Hi Garett,

thank you a lot.

But the TCP problem isn't the only one. It would be very nice if you could forward following problems too:

• The DHCP client loses its IP after a while. Example: If I set the lease time to 120s then the IP is lost after 16-17min. The DHCP client will start a new DHCP discover then
• After booting ACD doesn't work properly. The stack generates the telegrams (4 probes and 2 gratious ARPs) but they don't appear on ethernet reliable. While debugging the telegrams can be seen every time and they pass the stacks. But if you let the device run free, the telegrams seems to be swallowed somewhere and mostly only the gratious ARPs can be seen. It seems like a timing issue as it behave every time a little different...

Regards,

Stefan

Stefan,

Did you update NDK as per user guide for above tests especially for ACD?

• NOTE 2:

  To add ACD(Address Conflict Detection) support in the application, a legacy method is used for configuring NDK parameters. In this approach configuring of NDK is done using the Configuration APIs rather than the XGCONF configuration tool within CCS. This is because a configuration added through XGCONF tool will be overridden. Please refer the link for more information on this approach.

• NOTE 3:

  For passing the Subnet Mask tests (Test 4.1) specified in ODVA Conformance test report, rebuilding of the NDK is required. Macro _INCLUDE_ACD_SUPPORT must be defined in the file NDK_INSTALL_DIR\packages\ti\ndk\stack\lli\lliin.c. Then the NDK is rebuilt

Regards,

Garrett

Hi Garrett,

the NDK doesn't support the _INCLUDE_ACD_SUPPORT macro anymore. The "_INCLUDE_ACD_SUPPORT"-code is included per default. So rebuilding wouldn't change the object files...

Regards,

Stefan

Stefan,

Just wanted to let you know what we are looking into the issue as high priority, and will update you if any progress.

Regards,
Garrett

Hi Garrett,

this is Dominik, a co-worker of Stefans. May i ask what's the Status of our inquiry? As you are Looking into the issue with a high priority. Is there any Progress? We would really like to know because we have customers waiting for a feature release which we can't finish properly if we still have this open issue.

Regards,

Dominik

Hi Dominik,

Sorry to get back to you so late. Both I and the person who was planning to follow up with TMG and actively working on the issue are travelling, let me escalate the thread again...

Thanks,

Garrett

Hi Garrett,

i'm not really ammused to hear that - supposedly - no one was available to handle the high priority task on your end. 

Nonetheless, we assume that the problem lies not with the TMG stuff but more with the NDK, as we are not able to establish ANY TCP Connection anymore. So it might be worth also looking into the adaption and inclusion of the NDK. But we are not able to see where the error could be located as we are not totally familiar with the NDK itself, we just wanted to use that. 

regards

Dominik

Dominik,

We are seeing suspicious wMaxResponseDelay variable in EIP stack, trying to get better understanding from TMG, should be able to update you with more details soon.

Regards,
Garrett

Hi Garrett,

you are right with wMaxResponseDelay. It seems to high with a random value up to 2000ms to prevent response storms. But this only explains the delayed list identity responses.

The TCP problem seems to have its origin in an exhaustion of the PCBs inside the NDK. But we don't understand why its happening

Regards,

Stefan

Stefan,

We were able to narrow down the TCP issue to USER_NetworkTCPClose() api  in the stack which is moved from EPIC_PoolServerCloseSession() in v3.3.3 to EPIC_PoolServerClose() in v3.5.0. We can confirm that reverting this change fixes this problem.

We are actively working with TMG to get this issue resolved.

Thanks,

Garrett

Hi Garrett,

I've reverted this change and it fixes the problem for me too. I'm glad I can continue testing without beeing afraid to change all stacks later. Thank you very much for this

I found out the delayed responses for the list identities are intentional because of the specification. This must have changed in the specification not long ago...

So at the moment I'm struggeling with following problems left:

• The DHCP client loses its IP after a while. Example: If I set the lease time to 120s then the IP is lost after 16-17min. The DHCP client will start a new DHCP discover then
• After booting ACD doesn't work properly. The stack generates the telegrams (4 probes and 2 gratious ARPs) but they don't appear on ethernet reliable. While debugging the telegrams can be seen every time and they pass the stacks. But if you let the device run free, the telegrams seems to be swallowed somewhere and mostly only the gratious ARPs can be seen. It seems like a timing issue as it behave every time a little different...

I'm glad for every help you can give

Regards,

Stefan

Stephan,

The router with DHCP server built-in I am using doesn't have IP lease time configuration. Did you set up both default lease time and max least time to 120s? Let me try to set up a dhcp server on my Ubuntu PC and then get back to you, will check ACD feature as well...

Regards,

Garrett

Stephan,

I didn't measure the actual IP lost time but do notice the address lost after a while when I set the lease time to 120s. 

Can you please upload your wireshark traces for both the DHCP lease time and ACD issues? 

Thanks,

Garrett

Hi Garret,

sorry for the late response, but I had problems to reproduce the ARP problem. At first I thought it's fixed...

So I recorded 3 traces for you:

1. DHCP-discover.pcapng shows how the device is losing its IP after 16min.
2. ARP_good.pcapng shows how the device should send the ARPs after booting if ACD is enabled
3. ARP_badx3.pcapng shows how the device is started 3 times in a row. It should look like "ARP_good.pcapng" 3 times in a row...

The difference between 2) and 3) is the change from DHCP to static IP. In 2) DHCP is activated and some part of the stack has enough time to boot up and the ARP packets can be sent successfully. It's no problem for me to wait for the initialization. But I have to know for what...

Regards,

Stephan

2845.ti.zip

Hi Stephan,

Thanks for capturing the logs, let me check if my captures aligns with them....

Regards,

Garrett

Stephan,

My captures show the same time gap between two DHCP discover messages as yours, will look into it...

For ACD issue, if I understand you correctly that the issue occurs when using static IP address but it works fine with DHCP.

Regards,

Garrett

Hi Garrett,

sorry for the late response.

Yes with DHCP it works fine. I think that it's just a timing issue. Some task or initialization isn't ready for the case when the IP is available immediately.

Regards,

Stephan

Stephan,

As the thread already contains multiple Ethernet/IP issues/fixes, would you please open new thread if any further issues? Thanks.

Regards,
Garrett

Hi Garret,

sorry for the late response and thank you for the DHCP fix. I've tested it for a small lease time and it has worked.

So before marking this thread as solved there is one last issue:

• What I should wait for before sending the ARP frames because of ACD?

I think one thread isn't up properly when ACD tries to send the ARPs but I don't know which one...

Thanky you in advance

Regards,

Stefan

Hi Stefan,

You need to make sure following things

1) Need to make sure EIPACD_init is called and NS_setAddrHook is registered

2) Make sure Link callbacks are not triggered without initializing the module (eg EIPACD_start should be called before Link call back to ACD is registered)

Regards,

Prajith

Stefan,

The developers have updated the fix provided earlier.  Please update as follows:

diff --git a/third_party/protocols/ptp/ptpd/protocol.c b/third_party/protocols/ptp/ptpd/protocol.c
index d23d067241..4407781c75 100644
--- a/third_party/protocols/ptp/ptpd/protocol.c
+++ b/third_party/protocols/ptp/ptpd/protocol.c
@@ -249,7 +249,11 @@ protocol(RunTimeOpts *rtOpts, PtpClock *ptpClock)
if(!doInit(rtOpts, ptpClock)) {
ERROR("PTPd init failed - will retry in %d seconds\n", DEFAULT_FAILURE_WAITTIME);
// writeStatusFile(ptpClock, rtOpts, TRUE);
- fdClose(ptpClock->netPath.generalSock); /* PINDSW-3869 close the socket if some error occured.*/
+ if((ptpClock->netPath.generalSock) > 0)
+ {
+ fdClose(ptpClock->netPath.generalSock); /* PINDSW-3869 close the socket if some error occured.*/
+ ptpClock->netPath.generalSock = -1;
+ }
ptpClock->initFailure = TRUE;
ptpClock->initFailureTimeout = DEFAULT_FAILURE_WAITTIME;
} else {

Best regards,
Brad