• State Resolved
  • Locked Locked
  • Replies 15 replies
  • Subscribers 32 subscribers
  • Views 824 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM2434: Industrial Communications SDK PRP Demo Issue

Daisuke Maeda
Guru 20285 points
Part Number: AM2434
Other Parts Discussed in Thread: TMDS243EVM, LP-AM243, TMDS64EVM

The PRP demo in AM243x Industrial Communications SDK sends two replies for one ping request.

Our customer ran the PRP demo on the TMDS243EVM. The network for PRP was configured as follows.

TMDS243EVM (The PRP demo) - L2 Switch - PRP RedBOX - PC

I ran the PRP demo on the LP-AM243. The network for PRP was configured as follows.

LP-AM243 (The PRP demo) - L2 Switch - TMDS64EVM (Linux)

We captured and checked the packets of each of the two networks configured for PRP.

Please check the attached PDF file for details.

AM243x Industrial Communications SDK PRP Demo Issue.pdf

Best regards,

Daisuke

  • 0
    TI__Expert 7655 points

    Hi,

    Can you please share the pcap file for us to analyze? It would help if we can get the captures from both setup.

    Will also try to reproduce the issue at our side.

    Regards,
    Prajith

  • 0 in reply to Prajith Jayarajan
    Guru 20285 points

    Hi Prajith-san,

    Thank you for your reply.

    I did a new capture with the network configuration below.

    LP-AM243 (The PRP demo) - L2 Switch - TMDS64EVM (Linux)

    Attach a zip file containing pcap files for 2 ports.

    TMDS64EVM to LP-AM243.zip

    For the network configuration below I would request our customer to share the pcap file.

    TMDS243EVM (The PRP demo) - L2 Switch - PRP RedBOX - PC

    Do all packets from system startup need to be captured?

    Best regards,

    Daisuke

  • 0 in reply to Prajith Jayarajan
    Guru 20285 points

    Hi Prajith-san,

    Any updates?

    Are you finding anything by analyzing my attached pcap files?

    Best regards,

    Daisuke

  • 0 in reply to Prajith Jayarajan
    Guru 20285 points

    Hi Prajith-san,

    I have found one condition that causes the issue.

    The issue occurs when the RJ45 connectors on both boards are connected as shown below.

    LP-AM243 (The PRP demo): RGMII1 - L2 Switch - TMDS64EVM (Linux): RGMII1
    LP-AM243 (The PRP demo): RGMII2 - L2 Switch - TMDS64EVM (Linux): RGMII2

    The issue does NOT occur when the RJ45 connectors on both boards are connected as shown below.

    LP-AM243 (The PRP demo): RGMII1 - L2 Switch - TMDS64EVM (Linux): RGMII2
    LP-AM243 (The PRP demo): RGMII2 - L2 Switch - TMDS64EVM (Linux): RGMII1

    Is the issue a bug in the PRP demo? Or is it a limitation in the PRP specification?

    Please give me an answer as soon as possible. Your prompt reply would be appreciated.

    Best regards,

    Daisuke

  • 0 in reply to Daisuke Maeda
    TI__Expert 7655 points

    Hi Daisuke San,

    We have not seen this issue in our testing. I will test this at my side and update you at the earliest

    Regards,
    Prajith

  • 0 in reply to Prajith Jayarajan
    Guru 20285 points

    Hi Prajith-san,

    Thank you for your reply.

    For the network configuration below I obtained the pcap files from our customer.

    TMDS243EVM (The PRP demo) - L2 Switch - PRP RedBOX - PC

    Attach a zip file containing the pcap files for 2 ports.

    PC to RedBOX to TMDS64EVM.zip

    PC: 192.168.1.10
    TMDS243EVM (The PRP demo): 192.168.1.200

    The issue does NOT occur if the opposing RJ45 connectors are swapped, as was the case with the EVMs I tried.

    Please give me an answer as soon as possible. Your prompt reply would be appreciated.

    Best regards,

    Daisuke

  • 0 in reply to Prajith Jayarajan
    Guru 20285 points

    Hi Prajith-san,

    Any updates?

    Daisuke Maeda said:
    Is the issue a bug in the PRP demo? Or is it a limitation in the PRP specification?

    Please give me an answer as soon as possible. Your prompt reply would be appreciated.

    Best regards,

    Daisuke

  • +1 in reply to Daisuke Maeda
    TI__Intellectual 1920 points

    Hi Daisuke-san, 

    Thanks for sharing detailed information on the issue. I reviewed the captures and I see there is LAN-ID mismatch in the PRP network. 

    Ping Request: (LanId = B)

    1st Ping Reply: (LanId = A)

    2nd Ping Reply: (LanId = A)

    The PRP network expects that all ports having same LanId are connected together. If the LanId of the received packet does not match the LanId of the Port on which it is received, duplicate discard check is not done for those frames, and they are passed as is to the host. This will result in host receiving 2 ping request messages and therefore it will send out 2 response messages. 

    You can check counters like cntErrWrongLanA, cntErrWrongLanB to see if you are getting packets with wrong LanId on the evm. I think you can print these using application uart menu. (type s for printStatistics(), which in turn calls RedGetStatistics()) 

    Thanks, 
    Himanshu

  • 0 in reply to HIMANSHU MITTAL
    Guru 20285 points

    Hi Himanshu-san,

    Thank you for your reply.

    I confirmed the LanId mismatch by comparing the captured sent and received packets, and also confirmed that "WrongLan" was counted up in the statistics in the PRP demo.

    I understand that each packet with a wrong LanId received on both ports is proceed separately, so a reply is issued for each request received on both ports, and the reply is sent from both ports.

    Does the behavior for packets with a wrong LanId only occur with the PRP demo? Or does it occur with any PRP device?

    Is the behavior a bug in the PRP demo? Or is it a limitation in the PRP specification?

    Best regards,

    Daisuke

  • +1 in reply to Daisuke Maeda
    TI__Intellectual 1920 points

    Hi Daisuke-san, 
    This behaviour is expected and is as per IEC 62439-3. The network needs to be correctly configured with all LanId A ports being in same Lan (and LanId B ports should be in other Lan).

    From Spec:
    4.1.10.2.4 Use of LanId
    The 4 bit LanId field of the RCT carries a distinct identifier for LAN_A or LAN_B, specifically the codes 1010 (“A”) and 1011 (“B”). Therefore, the A-frame and the B-frame differ in one bit (and in the FCS). The receiver checks that the frame comes from the correct LAN. It does not reject a frame that comes from the wrong LAN, since this could be a legitimate frame which happens to have the PRP suffix and the length information in its last 28 bits, but it increments the error counters CntErrWrongLanA or CntErrWrongLanB since this hints at a configuration error. Since this kind of error is permanent, it is detected rapidly.

    Thanks, 
    Himanshu

  • 0 in reply to HIMANSHU MITTAL
    Guru 20285 points

    Hi Himanshu-san,

    Thank you for your reply.

    Is LanId fixed for each port? Or can it be changed?

    If it is fixed, is the correspondence between each MII interface and LanId as shown below?

    RGMII1 or MII0: LAN_A
    RGMII2 or MII1: LAN_B

    If it can be changed, how is LanId set in the PRP demo?

    Best regards,

    Daisuke

  • 0 in reply to HIMANSHU MITTAL
    Guru 20285 points

    Hi Himanshu-san,

    If the LanId can be changed (swap LAN_A and LAN_B) in PRP demo, how to set it?

    If not, is the LanId fixed as below?

    RGMII1 or MII0: LAN_A
    RGMII2 or MII1: LAN_B

    Please give me an answer as soon as possible. Your prompt reply would be appreciated.

    Best regards,

    Daisuke

  • +1 in reply to Daisuke Maeda
    TI__Intellectual 1920 points

    Hi Daisuke-san, 

    Sorry for delay here. 
    I checked the sources and LanId is fixed for ports. 

    Your understanding is correct:
    RGMII1 or MII0: LAN_A
    RGMII2 or MII1: LAN_B

    Thanks, 
    Himanshu

  • 0 in reply to HIMANSHU MITTAL
    Guru 20285 points

    Hi Himanshu-san,

    Thank you for your reply.

    HIMANSHU MITTAL said:
    I checked the sources and LanId is fixed for ports. 

    Is it because the LanId is set in the PRU firmware and cannot be changed by the user?

    Best regards,

    Daisuke

  • +1 in reply to Daisuke Maeda
    TI__Intellectual 1920 points

    Hi Daisuke-san, 

    > Is it because the LanId is set in the PRU firmware and cannot be changed by the user?

    Yes, it is fixed in firmware and to change it firmware will have to be modified and rebuilt. Also, currently we only test the configuration we are supporting, so changing it might result in some unexpected issues as well.

    Thanks,
    Himanshu