AM335x ISDK v2.1.0.1 PROFINET slave packet loss

Biser,

Thanks for following up.
I appreciate your return.

Best regards, RY

Hi,

Can I have any update?
We have to fix this issue by Mid/January.

Best regards, RY

Hi,

I have some questions regarding the setup.

1. Is that an actual Hub in the setup ? Because Hubs are half duplex and packet loss is possible due to that.

2. The capture says protocol type as ENIP but you are using a Profinet slave correct ? Please note that Profinet does not support half duplex functionality.

Regards

Vineet 

Hi Vineet-san,

I'm RY's colleague, I answer your questions instead of him.

> 1. Is that an actual Hub in the setup ? Because Hubs are half duplex and packet loss is possible due to that.

The actual Hub is Full duplex.

> 2. The capture says protocol type as ENIP but you are using a Profinet slave correct ? Please note that Profinet does not support half duplex functionality.

Yes. Because ENIP uses IP layer, I think it is no problem using ENIP on PRU-ICSS for Profinet.

Best regards,

Keigo Ishii

Hi Keigo-san

Noted. It's a holiday here due to Christmas so I will get back to you next week on this. Meanwhile if you could attach the wireshark captures it would be of great help.

Regards

Vineet

Vineet,

Thanks for your reply.
I would attach the capture data.
I appreciate you to check this.

Best regards, RY

switch_lost.zip

Hello RY,

It looks like to be a timing issue. Logs which you shared doesn't show correctly the relative timings between the frames. Is it possible for you to capture the log which shows correct timing relation between the captured frames.Meanwhile, we will try to reproduce this issue on our end. 

For my understanding, Why you are running EIP using the Profinet slave example ? You can very well run EIP using the "ethernetip_adapter" example/firmware. I say this because Profinet firmware has some Profinet specific functionality implemented in it which consumes the PRU cycles. For running EIP there is no need of this Profinet specific functionality. Can you try out once running the EIP over "ethernetip_adapter" while we reproduce and debug this issue ?

Regards,

Robin Singh

Robin,

Thanks for your support!
Sorry for my late reply, I checked latest ISDK.
But, our issue does not clear.

In our exam, it seems that descriptor data associated with the packet broke when collision occured.
I noticed mismatch in recieve packet actually by compare with MCU log.

Are you aware of this phenomena? I suspect it is errata.

To analyze it, we need ICSS LLD Driver source code because it is provided as binary.
Can you share individually? I have contacted local FAE in TI Japan.

Best regards, RY

Hello RY,

ICSS LLD Driver source code is open, it is located in "sdk\os_drivers\lld\" folder.  We provide the PRU Firmware as binary in the SDK. 

Regarding collision I have one question, how are you transmitting packet- E (from 192.168.1.10) ? Does host insert it in the transmit queue or is it transmitted over the PPM interface between host and PRU ? In our PROFINET implementation PPM frames are transmitted over a separate interface and not over the transmit queues.

Also, does the network analyzer which you used to capture the wireshark log of frames will capture the frame with CRC error /Short frames etc ?

Regards,

Robin

Robin,

I am sorry to confusing you.
First of all, packet loss issue was cleared by updating ISDK.
But, we encountered new issue.

In our exam, it seems that descriptor data associated with the packet broke when collision occured.
I noticed mismatch in recieve packet actually by compare with MCU log.

I will attach the new log as follows:

We need PRU Firmware provided as binary to analyze how descriptor broke.
Can you share individually?
(Sorry, ISDK LLD is my misunderstanding. We need PRU Firmware source.)

Comments regarding your quesion:

> Regarding collision I have one question, how are you transmitting packet- E (from 192.168.1.10) ?
> Does host insert it in the transmit queue or is it transmitted over the PPM interface between host and PRU ?
> In our PROFINET implementation PPM frames are transmitted over a separate interface and not over the transmit queues.

Host transmits using transmit queue of general purpose ethernet frame.
In detail, Host Queue4 is used. it is not used PPM frame.

> Also, does the network analyzer which you used to capture the wireshark log of frames will capture the frame with CRC error /Short frames etc ?

I think wireshark can not capture the illegal frame.
In our current situation, there is no packet loss. (Sorry to confusing you)
But, descriptor broke when collision occured. It can be seen from our MCU log.

Best regards, RY

Hello RY,

Can you please explain the new issue ? It is no clear from log to me that what is the issue ? 

Referring to your diagram from your first port, two frames( Packet A and B) arrive at Port 2 of 192.168.1.10 device and one frame is locally inserted by this device (Packet E). I don't think a collision can occur at the Port 1 of this device for this traffic.Packet A and B will either cut-through from Port 2 to Port 1 or they will be stored in the queue of opposite port only if Packet E is already getting transmitted on Port 1. So, collision can't happen for these three frames.

I am not sure if I can provide the PRU Firmware source code, I will have to check my with management if I can do that or what is the procedure. 

Regards,

Robin