MCU-PLUS-SDK-AM243X: EtherNet/IP Adapter Demos: ACD multiple port link-up

Hi Ryohei,

We have received your query. Allow us till End of this week to get back on it.

Which switch are you using here?

Hi Nilabh,

We conducted our tests using the following equipment:

HUB A: ELECOM EHC-G05PA-W-K 

Managed Switch B: Allen-Bradley 1783-BMS06TA  Stratix 5700

HUB A is a general hub and the time to link up is relatively slow.

Stratix 5700 switch's port rule is set to "Multiport Automation Device", so the time to link up is fast.

This error only occurs if switch A is slower to link up.

So, it does not occur if HUB A and Managed Switch B are swapped.

As a result, I think that in the current project, when a link-up of another port occurs in the ProbeIpv4Address state, the ProbeIpv4Address activity is not initiated again as it should be.

Volume 2: EtherNet/IP Adaptation of CIP - Figure F-1.1 ACD Behavior

Is the above operation in ProbeIpv4Address state implemented in this project?

Hi Ryohei,

the team now also performed the test with the old HMS tool now and got no error report on 8.5.8, thus it would be even more important to get access to Wireshark traces at least, also a description of the topology with the components in the setup would be required. We know that ACD is delicate depending on potential switches used in the setup. We tested ACD with multiple different switches and had seen that some of them don’t respect the timing constraints given by ODVA.

Hi Nilabh,

Thank you for your reply.

However, the test in which the error occurs is P8.5.6, not P8.5.8.

And I verified using HMS's ACDTest version v.1.14.0.1.

ACDTest Download URL

marketplace.odva.org/.../1812-address-conflict-detection-test-tool

Could you please check again regarding P8.5.6?

Hi Ryohei

I have forwarded the query to Kunbus, please expect a delay in response due to holidays. (expected reply day: Wednesday)

Hi Ryohei,

Could you please share the following details:

1. EVM used: TI EVM or Custom board?

2. Which PHY are using here, if you are using a custom board?

Hi Nilabh,

I also tagged "LP-AM243" in this thread, but I verified it using the LP-AM243 board Revision E3 & A.

Therefore the PHY is DP83869.

Hi Ryohei,

we will reperforming the ACD tests once we have the next release package available (working on that now). But I suspect that we will still see ACD test error in particular with the DLink Switch which is known to be quite slow after link up and cannot match the timing requirements set by ODA for the ARP probes.

Hi Nilabh,

We look forward to hearing the results of the ACD test rerun.

Hi Ryohei,

Even with re run of ACD test, we did not see the issue, could you please share the wireshark log here?

Hi Nilabh,

I have attached the log in case of an error.

ACDTest_1.14.0.1_P8.5.5&P8.5.6.zip

Hi Ryohei,

I have shared the logs with Kunbus team today(Got back from vaccation today). Lets wait for few days for Kunbus to come back with analysis.

Hi Nilabh,

We look forward to your reply.

We have new industrial comms sdk release fixing some of the previous issues: INDUSTRIAL-COMMUNICATIONS-SDK-AM243X Software development kit (SDK) | TI.com

Also can you try any other switch apart from DLINK

Hi Nilabh,

I conducted acd test again on ind_comms_sdk_am243x_09_01_00_03.

But, the results were the same as the previous version.

I don't use D-Link switches.

I have attached the results.

.ACDTest_1.14.0.1_P8.5.5&P8.5.6_ind_comms_sdk_am243x_09_01_00_03.zip

Hi Ryohei

The team can reproduce this behavior:

• It seems as under some circumstances the PRU does not send out the frames we are passing to it.

When we attach a “RevPi Connect 3” to the secondary ports, we see that the LINKUP-event for that 2nd port comes >1s later than the LINKUP-event for the first port (attached to NICs of our PCs). 2nd port usually comes up between 1st and 2nd announcement-frame, and the 2nd announcement can be received on PC..

When this “slow” device is attached while (fast, 10Hz) “ping”ing the DUT, one can see that the ping freezes for close to a second while the LINK is negotiated (admittedly in this situation the packets are late, but not lost).
The frames we pass to the PRU while the 2nd port of the DUT is coming up are lost.

Currently we are working on root causing the issue on TI end.

Hi Nilabh,

I understand the phenomenon of PRU.

Does this phenomenon occur with all PRU software?

Or is it just RPU software for EtherNet/IP?

Currently its seen only with EthernetIP. We are still working on debugging it.

Hi Nilabh,

Thank you for your reply.

I understand about the current situation.

We look forward to seeing your debugging results.

Hi Ryohei,

Thanks for your patience

Hi Nilabh,

Thank you for following up this thread. It would be appreciated if we can speed up to solve this issue because the customer has waited for more than three months.

Thanks and regards,
Hideaki

Hi Hideki,

We are currently trying to isolate the issue between the EIP stack and FW hal. We are working on expediting the solution as soon as possible.

After a thorough analysis, we found that the problem is caused by variations in link-up times and is not directly related to any bug or issue in the stack. Nevertheless, we have created a PR for a fix that addresses one shortcoming: while in the INITIAL_PROBE state, a link-up of the 2nd link will now restart INITIAL_PROBE. This functionality was missing before.

Despite this, we think that the reported "errors" with ACD tests, when link-up times vary significantly and may occur if the test does not anticipate such variations. We don't believe the test currently takes these situations into account.

If you need to address something else regarding to this situation, please let us know.

Hi Nilabh,

Thank you for your reply.

I understand that restarting INITIAL_PROBE will be supported.

What happened to the PRU issue below?

Nilabh Anand said:

The frames we pass to the PRU while the 2nd port of the DUT is coming up are lost.

Ryohei Yamada said:

Nilabh Anand said:

The frames we pass to the PRU while the 2nd port of the DUT is coming up are lost.

Hi Ryohei,

The issue was not related to PRI not sending frame, instead there were not enough frames being generated by the stack.

Hi Nilabh,

Thank you for your reply.

If it is confirmed that there is no problem with the ACD function in the next release version, I will close this thread.

I'll ask a question about PRU issues in a separate thread.

Hi Nilabh,

I have created a new thread below regarding the PRU issue.

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1326342/mcu-plus-sdk-am243x-frames-passed-to-the-pru-for-ethernet-ip-are-lost-while-the-second-port-is-up

Please respond to the thread above regarding PRU.

Sure Ryohei.

Hi Nilabh,

We performed operation verification in Early Access version 09.02.00.03 of INDUSTRIAL-COMMUNICATIONS-SDK-AM243X.

The result was that none of the issues we were inquiring about had been resolved.

The test below gives the same error as the previous version.

P8.5.6     Verification that multi port devices restart the ACD process on link up

P8.5.6 ***> Did not receive valid ARP in 10 seconds

The behavior is the same as the previous version, and only one ARP Announcement is output in P8.5.6.

I have attached the log.

ACDTest_1.14.0.1_P8.5.5&P8.5.6_ind_comms_sdk_am243x_09_02_00_03.zip

The behavior has not been improved, so please check.

Hi Ryohei,

I have enquired about this from Kunbus, they are retesting it on theri end. seems like a mismatch in terms of requested bug fixes, please allow me sometime to get back here.

Hi Ryohei,

If both ports of the EIP slave do not give link up at the same time then stack will consider the one who gets the link up first. So the below resolution would still stand correct here.

Nilabh Anand said:

After a thorough analysis, we found that the problem is caused by variations in link-up times and is not directly related to any bug or issue in the stack. Nevertheless, we have created a PR for a fix that addresses one shortcoming: while in the INITIAL_PROBE state, a link-up of the 2nd link will now restart INITIAL_PROBE. This functionality was missing before.

Despite this, we think that the reported "errors" with ACD tests, when link-up times vary significantly and may occur if the test does not anticipate such variations. We don't believe the test currently takes these situations into account.

If you need to address something else regarding to this situation, please let us know.

Hi Nilabh,

Is it still only considering the first link-up, or has it been modified to restart the INITIAL_PROBE state during the second link-up if it occurs during the second INITIAL_PROBE state?

Comments considering only the first link up (Not considering second link up)

Nilabh Anand said:

If both ports of the EIP slave do not give link up at the same time then stack will consider the one who gets the link up first. So the below resolution would still stand correct here.

Comment to restart INITIAL_PROBE if second linkup occurs during INITIAL_PROBE (Considering second link up)

Nilabh Anand said:

After a thorough analysis, we found that the problem is caused by variations in link-up times and is not directly related to any bug or issue in the stack. Nevertheless, we have created a PR for a fix that addresses one shortcoming: while in the INITIAL_PROBE state, a link-up of the 2nd link will now restart INITIAL_PROBE. This functionality was missing before.

These two comments are contradictory.

Which one is correct?

Ryohei Yamada said:

Nilabh Anand said:

After a thorough analysis, we found that the problem is caused by variations in link-up times and is not directly related to any bug or issue in the stack. Nevertheless, we have created a PR for a fix that addresses one shortcoming: while in the INITIAL_PROBE state, a link-up of the 2nd link will now restart INITIAL_PROBE. This functionality was missing before.

This is the correct statement. We are working on checking why initial probe is not restarting on 2nd port link up.

Hi Anand,

Thank you for supporting this thread. 

Nilabh Anand said:

We are working on checking why initial probe is not restarting on 2nd port link up.

Could you tell us what the current status is ?

Please accelerate to solve this issue as soon as possible.

Thanks and regards,
Hideaki

Hi Archit,

Thank you for your reply.

We are looking forward to the release of Industrial Comms SDK v9.2.

Thank you for your patience. 

Regards
Archit Dev

Hi Archit,

Thank you for releasing Industrial Comms SDK v9.2.

It was confirmed that the ACD test P8.5.6 passed due to the added delay setting by EI_API_ADP_setAcdDelay.

I have attached the results.

The issue has been resolved, so I will close this thread.

ACDTest_1.14.0.1_P8.5.5&P8.5.6_ind_comms_sdk_am243x_09_02_00_08.zip