IND-COMMS-SDK: AM6421 Profinet Netload Test Fails

Philip Kees

Part Number: IND-COMMS-SDK

Tool/software:

Hi All,

when doing netload tests (Class 3) with our custom Profinet Device using IND_COMMS_SDK 9.2.0.18 we encounter different test fails:

TC101: Only initial DCP Ident response sent by device, no response from device after any of the DCP bursts

TC7 + TC9 (normal): Breakdown of RT Communication betweel PLC and device, if acyclic communication is enabled in parallel. If no acyclic communication is enabled for the tests, they are pass.

Within our device we have two additional tasks on the Profinet R5 handling the RpMsg communication for Cyclic and Acyclic data to a A53 Core running Linux. These tasks have priotities 23 (acyclic) and 24 (cyclic).

We then tested to reduce the priorities below 20 (my understanding is that the stack uses 20 upwards) which seemed to fix the issue but when running the tests continously through the night we still encountert these fails. This time with additional fails in faulty test scenarios.

If someone could provide guidance on how to improve the devices behaviors for these cases or how to properly set the priorities for application tasks I would appreciate it. I looked thorugh the docs but am not aware on infos regarding this.

Thank you and kind regards

Philip

7 months ago

0 Philip Kees 7 months ago

Prodigy 105 points

I just received an update from the Tester, it seems that now the tests are failing consistently again, with no change to the R5 binary. At the moment we cant see any pattern on factors that might influence the outcome.

0 Laxman Chinnannavar 7 months ago in reply to Philip Kees

TI__Expert 3110 points

Hi Philip,

We are making few fixes in the stack and driver to improve the performance of the device with Netload tests. I will discuss with the team to provide the latest patches for you to test the failing scenarios.

I would like to understand more about the behavior of the device after the Netload Faulty test case. Since the Netload Faulty tests fail, I assume its most likely due to the communication between PLC and device being discontinued. Could you run few tests after the faulty failure?

1) Are you able to ping the device?

2) Can you share a memory dump from address 0x30090000 to 0x30092000?

3) Also could you share a wireshark log to check the device behavior?

Regards,
Laxman

0 Philip Kees 7 months ago in reply to Laxman Chinnannavar

Prodigy 105 points

Hi Laxman,

thank you for the quick reply, we are working on getting the requested infos and I'll update here as soon as we have them.

Thank you and kind regards
Philip

0 Philip Kees 7 months ago in reply to Laxman Chinnannavar

Prodigy 105 points

Hi Laxman,

I attached the dump to this reply.
We tested to ping the device after the failed test (TC7 Faulty), which did not work. Switching between PLC and additional Profinet Device in the test setup still works.
The Wireshark log will be next, I'll send it as soon as we have it.

Thank you and kind regards
Philip

devmem_0x30090000-0x30092000.zip

0 Philip Kees 7 months ago in reply to Laxman Chinnannavar

Prodigy 105 points

Hi Laxman,

I sent you a link via mail to our share system where you can download the requested Wireshark Logs.
If you have any questions, feel free to ask.

Kind regards
Philip

0 Laxman Chinnannavar 7 months ago in reply to Philip Kees

TI__Expert 3110 points

Hi Philip,

Thank you, I have received the logs.

I had a quick look at the shared logs and looks like only unidirectional traffic is captured (Frames sent from PLC to device), while frames sent from device to PLC are not present. Would it be possible to share the logs for bidirectional traffic? Also it would be sufficient if you could share the wireshark logs after faulty failure and not during the test. This would reduce the capture log size and also help us understand why the connection is not reestablished.

From the initial analysis, it looks like PLC is trying to connect to the device but device is raising an alarm and aborting the AR. I will need to check the frames sent by device to understand why it is aborting the AR.

Best regards,
Laxman

0 Laxman Chinnannavar 7 months ago in reply to Laxman Chinnannavar

TI__Expert 3110 points

Hi Philip,

Follow up question, Are you consistently able to reproduce the Netload Faulty failure by selectively running test case 7?

Regards,
Laxman

0 Philip Kees 7 months ago in reply to Laxman Chinnannavar

Prodigy 105 points

Hi Laxman,

sorry for the incomplete log. I sent you a transfer with traffic in both directions.

Regarding your previous question, I'll clarify with our tester since I'm not 100% sure and get back to you shortly.

Thank you and kind regards
Philip

0 Philip Kees 7 months ago in reply to Laxman Chinnannavar

Prodigy 105 points

Hi Laxman,

I got the confirmation that the fails happen consistently. For faulty test modes it seems that they only pass if the Priority of our cyclic RpMsg task is set to 29.

Kind regards
Philip

0 Laxman Chinnannavar 7 months ago in reply to Philip Kees

TI__Expert 3110 points

Hi Philip,

Thank you for sharing the updated logs. I will review these and get back to you with any updates.

Regards,
Laxman

+1 Philip Kees 6 months ago in reply to Laxman Chinnannavar

Prodigy 105 points

Hi Laxman,

we just received the news that all tests are passed for our device and all open points are resolved.
Thank you to you and everyone at TI who supported us in achieving this.

Kind Regards
Philip

0 Laxman Chinnannavar 6 months ago in reply to Philip Kees

TI__Expert 3110 points

Hi Philip,

Great to hear that all issues are resolved!

Best Regards,
Laxman

Processors

Processors forum

IND-COMMS-SDK: AM6421 Profinet Netload Test Fails