• State Resolved
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 252 views
  • Users 0 members are here
Support feedback
Options
Options
Related

Original question:

AM2432: Profinet Link State deactivation on custom boards

AM2432: AM2432: Profinet RT Test Diagnosis CheckPeers Scenario 2 failed

Andrea Politano
Prodigy 170 points
Part Number: AM2432


Tool/software:

Hi,

I am using AM2432 with the Industrial SDK 11.00.00.08.

The Profinet certification laboratory has reported us a problem (with test bundle v2.45):

  • Diagnosis Scenario 2: There is no alarm received for CheckPeers.

This is part of the log:

20 16:20:02: Diagnosis with CheckPeers Second Scenario: Diagnosis with CheckPeers
21 16:20:02: Performing a power cycle of the DUT.
22 16:20:32: Diagnosis with CheckPeers Test step 1: Switch the DUT off and on
again.
23 16:21:07: Diagnosis with CheckPeers Test step 2: Prepare the DUT for the test
run.
24 16:21:08: Diagnosis with CheckPeers Test step 3: CheckPeers: Check Precondition
25 16:21:08: Diagnosis with CheckPeers Test step 4: CheckPeers: Establish IOC-AR.
PDPortDataCheck with CheckPeers shall also be written while parametrization
with correct data to the port connected to neighbor 'D'.
26 16:21:08: Diagnosis with CheckPeers Test step 5: CheckPeers: PDPortDataCheck
validation.
27 16:21:08: Diagnosis with CheckPeers Test step 6: CheckPeers: ModuleDiffBlock
validation.
28 16:21:08: Diagnosis with CheckPeers Test step 7: CheckPeers: DataStatus
validation.
29 16:21:09: Diagnosis with CheckPeers Test step 8: CheckPeers: Diagnosis
validation.
30 16:21:09: Diagnosis with CheckPeers Test step 9: CheckPeers: Set Link of
Interface 2 to LinkState down.
31 16:21:09: Diagnosis with CheckPeers Test step 10: CheckPeers: Alarm validation.
32 16:21:12: Diagnosis with CheckPeers Test step 11: Exactly one alarm shall
occure. There was none.

I saw what the test does, and it seems that it checks whether our Profinet device can detect that a nearby device (simulated by ETS) is no longer connected and then sends an alarm.

I saw that three subtests are performed: with CheckMAUType, with CheckPeers, and with CheckLinkState. Since we have a custom PHY, in the GSDML we declare LinkStateDiagnosisCapability to none and CheckMAUTypeSupported to false, so we skip the tests with CheckMAUType and CheckLinkState because of preconditions not satisfied. However, the CheckPeers test only requires having two ports as a precondition, so I would expect that the test depends more on the Profinet stack or Profinet application than on the PHY. But this case fails anyway.

What could be the cause? What can I check and what other tests can I perform to verify that it is functioning correctly?

Thank you,

Best Regards,

Andrea

  • 0
    TI__Expert 3070 points

    Hi Andrea,

    Thank you for your query.

    We would need some logs related to the test failure to get a better understanding of the issue. For initial review, could you share the ART test report and the wireshark logs corresponding to the failing test case? 

    Best Regards,
    Laxman

  • 0 in reply to Laxman Chinnannavar
    Prodigy 170 points

    Hi Laxman,

    I attach the report and the wireshark log. The reports also include the subtest with CheckLinkState because it was not yet clear, but what interests us now is only the one with CheckPeers, since it has no particular preconditions.

    Thank you,

    Best Regards,

    Andrea

    Records Diagnosis Scenario 2.zip

  • 0 in reply to Andrea Politano
    TI__Expert 3070 points

    Hi Andrea,

    Kindly let us know if you are able to reproduce the issue on AM243x-EVM and we would be able to assist you further on this issue. As the failure is currently reproducible only on a custom board, this request is qualified as non standard. Please contact your TI sales representatives for direct support on this issue

    Best Regards.

    Laxman

  • 0 in reply to Laxman Chinnannavar
    Prodigy 170 points

    Hi Laxman,

    thank you for your reply.
    I just have a general question about how CheckPeers works to understand if it is actually caused by our custom board. Is the CheckPeers operation based on the status and informations of the PHY read by the module? In our custom architecture the second port declared in the GSDML (where the test fails) is not the one directly on the module but is a port on an external module, that is then connected to the Profinet module. This would explain why no alarm is sent, because the module only checks the status of its port and not the status of the other port outside the module. Is that correct?

    Thank you,

    Best Regards,

    Andrea

  • +1 in reply to Andrea Politano
    TI__Expert 3070 points

    Hi Andrea,

    Apologies for the delay in response.

    Andrea Politano said:
    This would explain why no alarm is sent, because the module only checks the status of its port and not the status of the other port outside the module. Is that correct?

    When the ETS disables the link on IF2 (Port 2), the device should detect this link-down status and send an alarm notification through the still-active Port 1. According to the Wireshark logs, this alarm isn't being sent.

    Your assessment about the external module seems plausible. The CheckPeers operation relies on the PHY status information that's directly available to the Profinet stack. In your custom architecture, since Port 2 is physically located on an external module, the Profinet stack might not be receiving the link status changes from that external port.

    To verify this hypothesis, I would suggest checking if link status changes on Port 1 (which is directly on the module) are correctly detected and reported. If Port 1 works properly but Port 2 doesn't, it confirms that the issue is related to the external port configuration and how link status information is passed between the external module and the stack."

    Best Regards,

    Laxman