This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
This question is about the PRU issue for EtherNet/IP in the thread below.
I built the demo below and checked its operation.
"ethernetip_adapter_generic_device_mii_demo_am243x-lp_r5fss0-0_freertos_ti-arm-clang"
We checked with new version 09.01.00.03 of INDUSTRIAL-COMMUNICATIONS-SDK-AM243X.
It has been confirmed that when two Ethernet ports are linked up with a time difference, all frames sent to the PRU during link up of the second port are lost.
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.
What is the status of this issue?
Hi Ryohei,
There is no PRU issue here wrt ACD functionality. The statement above "The frames we pass to the PRU while the 2nd port of the DUT is coming up are lost." was made during the initial debug.
The final status as of now is mentioned by Nilabh here https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1278975/mcu-plus-sdk-am243x-ethernet-ip-adapter-demos-acd-multiple-port-link-up
I will check with Kunbus on the current status and let you know
Regards,
Prajith
Hi Prajith,
In this thread, we are only asking about PRU issues, not ACD operation.
It has been reported that the KUNBUS stack will be fixed in the next release version of ACD, and if there are no problems in the next release version, the ACD issue will be resolved.
However, the PRU issue remains a problem that I believe should be fixed.
Although the PRU problem does not affect ACD, we believe that packet loss during link up will affect other operations.
Since this is a PRU issue, the inquiry will not be directed to KUNBUS, but to TI.
Hi Ryohei,
Thanks for the clarification.
There is no issue with respect to PRU. The icss emac driver has checks in place to make sure Link is up before sending a packet to PRU. The application/ stack can take necessary action based on the return value from the TX API.
Regards,
Prajith
Hi Prajith,
We performed operation verification in Early Access version 09.02.00.03 of INDUSTRIAL-COMMUNICATIONS-SDK-AM243X.
However, test errors are occurring due to the same ACD behavior as in the previous version.
We will make a determination as to whether this PRU issue has any impact on ACD behavior as soon as we confirm that ACD behavior has improved.
We performed operation verification in Early Access version 09.02.00.03 of INDUSTRIAL-COMMUNICATIONS-SDK-AM243X.
However, test errors are occurring due to the same ACD behavior as in the previous version.
We will make a determination as to whether this PRU issue has any impact on ACD behavior as soon as we confirm that ACD behavior has
Hi Ryohei,
This is not a valid issue, it was just a wrong deduction of problem. The ACD issue will happen if both ports do not see link up at the same time.