• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 33 subscribers
  • Views 376 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.

AM4378: Profinet PRU issue

Martin Wietfeld
Prodigy 30 points


Hello,

I'm developing the MRP part of a profinet implementation on an AM437x.

Unfortunately the PRU generates millions of telegrams, which have to be received by my application, although they are not real.

As one can see, the PN-MRP-telegram is reapetely forwarded by the PRU every 7 MICROseconds, which gives my nearly no time for my application, because I have to react on every telegram, even on those non real telegrams. Even, if I do a simple detection of these doubles, I will have nearly no time for my application.

If I change the forwarding tables BSP_ETH_PRUICSS_DRV_PN_P1_FW_MAC_TABLE and BSP_ETH_PRUICSS_DRV_PN_P2_FW_MAC_TABLE in bspEthPruicssDrvPnDefines.h

from

#define BSP_ETH_PRUICSS_DRV_PN_P1_FW_MAC_TABLE \
{ \
    0x00000003, /* 01-0E-CF-00-00-00  ..  01-0E-CF-00-00-1F */ \
    0x00000000, /* 01-0E-CF-00-00-20  ..  01-0E-CF-00-00-3F */ \
    0x00000000, /* 01-0E-CF-00-00-40  ..  01-0E-CF-00-00-5F */ \
...

    0x00000000, /* 01-0E-CF-00-05-C0  ..  01-0E-CF-00-05-DF */ \
    0x00000000, /* 01-0E-CF-00-05-E0  ..  01-0E-CF-00-05-FF */ \
    0x00000006, /* 01-15-4E-00-00-00  ..  01-15-4E-00-00-1F */ \
    0x00000001  /* 01-80-C2-00-00-00  ..  01-80-C2-00-00-1F */ \

to

...

    0x00000000, /* 01-0E-CF-00-05-C0  ..  01-0E-CF-00-05-DF */ \
    0x00000000, /* 01-0E-CF-00-05-E0  ..  01-0E-CF-00-05-FF */ \
    0x00000000, /* 01-15-4E-00-00-00  ..  01-15-4E-00-00-1F */ \
    0x00000001  /* 01-80-C2-00-00-00  ..  01-80-C2-00-00-1F */ \

then I get the following wireshark output:

Now I get millions of repeately forwarded ARP telegrams, again with a high speed repeatig time of 8 MICROseconds.

As ARP telegrams are broadcast telegrams (ff:ff:ff:ff:ff:ff) and there is no entry in BSP_ETH_PRUICSS_DRV_PN_P1_FW_MAC_TABLE and BSP_ETH_PRUICSS_DRV_PN_P2_FW_MAC_TABLE

I can't change any more entries in these tables to avoid the problem.

If I restart and do not resume (F8) my application, meaning it is hold forever at the first line of main(),

then I get this qireshark output:

Now the PN-DCP-telegrams are repeated forever, because the PRU has been started automatically, giving the PRU the chance to forward telegram on its own will.

I'm wondering how these mentioned tables work at all, because they only consist of bits, which activate/deactivate the forwarding from the corresponding addresses, but they do not include the MAC addresses.
So the referenced MAC addresses must be hard-coded in the firmware of the PRU.

What can I do to solve the problem?

Martin

  • 0
    TI__Mastermind 43296 points

    Hi Martin,

    Are you porting your own stack based on the PRU firmware from Profinet slave package? 

    Do you have access to the PRU firmware source code?

    The wireshark captures are not shown properly in the thread.

    Regards,
    Garrett

  • 0 in reply to Garrett Ding
    Prodigy 30 points

    Yes, I'm porting my own stack based on "PRU-ICSS-Profinet_Slave_01.00.02.02_v1_0", but I do not have access to the source code.

    >> The wireshark captures are not shown properly in the thread.

    I don't see a single bit of my three wireshark captures. How can you see them sat all?

    Martin

  • 0 in reply to Martin Wietfeld
    Prodigy 30 points

    I have found the problem in my environment, it is a network sniffing device, which I use to capture every telegram from the two MRP rings.

    This causes the "repeated telegrams" in my wireshark captures.

    So, for now, there seems to be no issue regarding the PRU and its forwarding of telegrams.

    Sorry for the trouble.

    Martin