• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 1640 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TIDM-DELFINO-ETHERCAT: EtherCAT header - byte order.

Dawid Balcerzak
Expert 1365 points
Part Number: TIDM-DELFINO-ETHERCAT

Hello,
I am analysing EtherCAT frame using wireshark and I found something doesn't fit to ESC documentation. In document ESC technology I can find out that EtherCAT header looks like this:

In wireshark capture I can see this:


Length: 0x059
Res: 0x0
Type: 0x1
According to picture from documentation I would say that EtherCAT header should look like this:
0x059 0x00 0x01 which is 0x5901 together (equals 01011001 00000001 b).
As you can see wireshark shows that second byte is different and EtherCAT header equals 0x5910 which is 01011001 00010000 b. It looks like order is different and it is: Length -- Type -- Reserved. In documentation I can't see anything about swaping bytes.
That situation makes me a little bit confused.

How can I explain it?

I appreciate any help.

Best regards,
Dawid.

  • 0
    TI__Mastermind 30255 points
    Hello

    I will sync with those on the familiar with wireshark and let you know what I find.

    Best regards
    Chris
  • 0 in reply to Christopher Chiarella
    Expert 1365 points

    I appreciate your help, thank you.

    Here is another example of strange byte order from the same frame.

    Let's taka a look on a NOP datagram. Here is offset addr field:


    As you can see, bytes are swapped and to be honest I don't know why.


    Here is Length field:


    In manuals I read that order is: Len-R-C-M but in wireshark capture it looks like this: Len-M-C-R. Even if I would swap bytes like in offset address field I would say it was like that: 01 04. Without swaping: 04 01. I don't understand why the second octet is bit-reversed. Or the other hand - it looks like the order is reversed (M-C-R-Len) and bytes are swapped. But as I said - I completely have no idea what is going on here and I can't see any explanation in manual. E.g., source and destination addresses and ethertype are sent without any swapping and it looks exactly like in manual.

  • 0 in reply to Dawid Balcerzak
    TI__Mastermind 19810 points
    Dawid,
    The raw stream of bytes that you are seeing in the network are in network order, big endian. The parsed bytes as per the protocol decoding of the datagram are converted to little endian as needed.

    I don't see any issue with what you are observing.

    Hope this helps.

    Best Regards
    Santosh Athuru
  • 0 in reply to Santosh Athuru
    Expert 1365 points
    Santosh,

    let's take a look at Offset Addr: 0x0900. When I write it as 0x00 0x09 I think it is little endian, isn't it?

    Now, let's take a look at Length. Manual says that order is: Len-R-C-M which is 0x04 0x01 when we take a look at values (0x01 0x04 in little endian). When we change order to Len-M-C-R then result is like in wireshark: 0x04 0x80 or 0x80 0x04 in little endian.

    I have no problem with little or big endian. I have a problem with order of bits - I don't know why 'last indicator' bit is in MSB position in wireshark when in manual it is LSB.
  • 0 in reply to Dawid Balcerzak
    Expert 1365 points

    Another example to explain what I mean. Let's consider two bytes: 0x01(MSB) 0xF0 (LSB). In big endian value is 0x01F0. In little endian value is 0xF001. But when I look on wireshark capture my data (0x01(MSB) 0xF0 (LSB)) would be sent as 0x010F and I don't understand why the lower bytes are bit reversed.

  • 0 in reply to Dawid Balcerzak
    TI__Mastermind 30255 points
    Dawid

    Remember these are bits, each (cmd, rsvd, length) aren't a byte each. In bits (in little endian), you see 0001 0 00001011001 as cmd, rsvd, length or 0x1059. Sent in big endian it would be 0x5910 as wireshark shows.

    Best regards
    Chris