AM2434: Interoperability issue on AM243x‑EVM – Devices behind DUT lose connection

Hello Vit,

Thanks for your inquiry!

1. Would you please try to increase the configured cycle period of the DUT ("Update time" in TIA portal) gradually from 1ms up?

2. Would you please also try to reduce the number of devices connected after the DUT?

Does this resolve your problem? please capture and share the new Wireshark traces.

Kind regards,
Kamil

Hello kamil,

we have tried same setup with EVM kit with example loaded into kit. Here are wireshark results for 1ms and 8ms from test lab.

20260122-EVMKIT-INTEROP-LEGACY-test.zip

For reduced number of devices, right now we don't have possibility to log this configuration on our setup where we had 1 device which didn’t work properly too. But this case with multiple devices is necessary for us to get certification as it's in specification for interoperability test by PI organization.

Best regards,

Jan

Hello Jan,

1. I was looking at the files you shared and I guess we have a little misunderstanding. I previously asked you to increase the cycle period on the DUT only, while keeping the remaining devices on 1ms. Since you have many devices I would start with the maximum possible cycle period on the DUT and see what happens. Unfortunately I don't have as many devices on my desk to try this myself. (This is the first trace to share with us).

2. On another note, I find it quite interesting that the devices send an "AR consumer DHT/WDT expired" alarm even though the process data seem to be transmitted by the PLC on time (the time difference between the last message from the PLC and the alarm is way less than the minimum watchdog time). This might indicate that some cyclic messages arriving to the DUT from the PLC are not forwarded to the corresponding devices (or being delayed). Would you be able to connect the TAP to port1 of any of the failing devices? just to verify if the cyclic messages are actually arriving to the device on time or not? (This is the second trace to share with us).

Thank you.
Kind regards,
Kamil

Hello Kamil,

Thise logs were provided by Siemens lab where we were getting our certification. So we will not be able to do more tests. On our setup we don’t have tap adapter for logging unfortunately. But we were able to replicate similar behaviour with only 1 device with this connection. Also here is binary we used for EVM kit in case there is some issue with our configuration or compilation.

PN_example_SDK_IND_11000013.zip

Best regards,

Jan

Please, replicate the issue on your side.

Use an older PLC (S7-300 CPU319F-3 PN/DP) that supports "Legacy IRT" only, your TI "AM243x‑EVM" device, and another Profinet IRT device (Siemens ERTEC).

Please focus on the Industrial Communication SDK 11.00.00.13, which is the version covered by your PROFINET IO Device Certificate No. Z14126.
cl.profibus.com/index.php
(At this project stage, we cannot upgrade to a newer SDK. Nevertheless, please note that the issue is also present when using the latest SDK.)

Configure the IRT communication and use connection topology as depicted by Jan:
PLC <-> TI DEVKIT <-> PN IRT (line topology).

1) Can you observe the communication issue?
2) Please also test the attached "AM243x‑EVM" binary (provided by Jan) and let us know whether it works or not. (This will help us verify that the issue is not caused by an incorrect project compilation on our side.)

Thank you in advance for your support.

Kind regards, Vit

Hi Jan & Vit,

we already tried to reproduce this scenario on our side last week. The main difference we have from your topology is that we're using a newer PLC with enforced legacy startup. We were able to see an issue that looks similar to what you described (but not identical). The issue was resolved by increasing the cycle period TI device. 

Regardless of this "workaround solution", we suspect that there's some little delay in the DUT's forwarding mechanism causing the following devices to receive their RTC3 frames outside the red period. This leads to internally dropping the frames even if they're seen on Wireshark.

We'll look further into this and send you feedback ASAP.

Kind regards,
Kamil

Hello,
we have verified the following behavior:

- with a PLC "send clock" of 0.5 ms, increasing the "update time" just for the DUT does not work
- with a PLC "send clock" of 1 ms (and higher), the DUT "update time" must be at least 2x longer than the PLC "send clock"
Additionally, when changing the IRT timing, it appears to be always necessary to restart the DUT (power cycle), maybe the ICSS unit seems to enter an inconsistent state otherwise.

1) Could you please inform us when both IRT-related issues are expected to be resolved?
2) Furthermore, since the DUT (your AM243x‑EVM devkit) device was successfully certified in the past with Industrial Communication SDK v11.00.00.13, we would like to understand how full certified functionality was ensured, specifically including the "IRT Legacy" communication?

Best regards,
Vit

Hello Vit,

We were able to figure out the problem and we're resolving it now. It is exactly as I assumed in the previous message. I will keep you posted!

1. Standard ind_comms_sdk supports minimum update time of 1ms. If you are interested in lower update times, you need the premium ind_comms_sdk. In this case, please reach out to your regional sales representatives for deliveries.
2. DUT power cycle issue with IRT timing change was resolved in our latest standard release (V: 2025_00_00_08).
3. The certification of our device was done by a certified test lab, using the Automated RT tester, Netload, Spirta and other different types of manual testing.

Kind regards,
Kamil

Hello Kamil,

thank you for the information.

Are you able to estimate when the "Interoperability IRT legacy" bug will be fixed?
And in which Industrial Communication SDK version it will be included (or backported)?

Kind regards,
Vit