Post Go back to editing
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SES AddDevice error -1

Thread Summary

The user encountered a SES AddDevice error -1 while running the Linux example-app for the EVAL-ADIN6310 board. The issue was resolved by changing the host strapping on the EVAL-ADIN6310 to 100 Mbps and ensuring auto-negotiation was enabled on both the BeagleBone Black and the EVAL-ADIN6310. The BeagleBone Black was also set to advertise only 100BaseT to avoid duplex mismatches.
AI Generated Content
Category: Software
Product Number: EVAL-ADIN6310EBZ
Software Version: ADINx310_TSN_Driver_Library_Rel6.0.1-GA

I have successfully configured the EVAL-ADIN6310 board from Windows and now am trying the Linux example-app.  The app runs, but returns SES AddDevice error -1.  I have built the app on a Beaglebone Black running Debian Trixie.  The app and example.xml file are in the same directory.  I copied the yang modules from sysrepo-glue-srv to /usr/share/yang/modules/.  (Note that without sudo, I get error -602, which I believe indicates the app is unable to access the Ethernet port.)

$ sudo ./ses-example-app -f example-eval-6310.xml -p f4:b8:98:86:3f:bd -i production
Board settings file is located at example-eval-6310.xml
Yang modules folder /usr/share/yang/modules/
libyang[0]: Value "7A" was not found in the dictionary.
libyang[1]: String "7A" not freed from the dictionary, refcount 1
Device MAC: 7A:C6:BB:11:11:11
Init with host MAC: F4:B8:98:86:3f:bd
SES AddDevice error -1

I ran tcpdump and can see activity from the beaglebone but there is no response from the ADIN6310.  The board strapping is the same as what works for windows (all jumpers in place except Timer2).  Link lights are on at both ends and ifconfig says the link is UP.  

$ sudo tcpdump -i eth0 ether proto 0xAAC5 -XX
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:31:26.246382 f4:b8:98:86:3f:bd (oui Unknown) > 7a:c6:bb:11:11:11 (oui Unknown), ethertype Unknown (0xaac5), length 60:
0x0000: 7ac6 bb11 1111 f4b8 9886 3fbd aac5 f000 z.........?.....
0x0010: 0000 1900 5600 1400 0100 0000 0900 0000 ....V...........
0x0020: 0800 0000 6800 0000 0200 0000 0000 0000 ....h...........
0x0030: 0000 0000 0000 0000 0000 0000 ............
15:31:27.247781 f4:b8:98:86:3f:bd (oui Unknown) > 7a:c6:bb:ff:fe:00 (oui Unknown), ethertype Unknown (0xaac5), length 60:
0x0000: 7ac6 bbff fe00 f4b8 9886 3fbd aac5 f000 z.........?.....
0x0010: 0000 1900 5600 1400 0200 0000 0900 0000 ....V...........
0x0020: 0800 0000 6800 0000 0200 0000 0000 0000 ....h...........
0x0030: 0000 0000 0000 0000 0000 0000 ............

I see other people were stuck at this same point using SPI, but I am using Ethernet.  

Can anyone suggest next steps to troubleshoot?  TIA, -Steve

Edit Notes


[locked by: CatherineR at 8:41 AM (GMT -4) on 7 Aug 2026]
  • Hi Steve,

    You're right sometimes the host prevents the application in accessing the Ethernet port, so using sudo usually resolves this.

    I’d like to confirm the Ethernet speed of the BeagleBone Black. The output you shared seems to indicate that it’s running at 10 Mbps.

    Could you set the Ethernet speed to 100 Mbps by only advertising 100BaseT.

    Also, change the host strapping of the EVAL-ADIN6310 for 100 Mbps operation?

    Regards,

    Karl

  • Karl:

    Success.  Changing the strapping on the EVAL-ADIN6310 was the missing piece of the puzzle.  I had already used ethtool to force the beaglebone to 100M but it is necessary to force the ADIN6310 to 100M.  Glad I found this now and not after building my own board.  Thanks,

    -Steve

    •  Analog Employees 
    on Aug 6, 2026 10:09 AM in reply to subseaSteve Contains AI Generated Content
    0

    Hi Steve,

    Just want to highlight that forcing speed (if this means Auto-neg is disabled) on the Beaglebone side may end up with the ADIN1300 PHY on our evaluation board bringing up a Half duplex link. 

    In your own design, you would likely have a MAC to MAC connection, so a forced mode on both sides in that case is exactly how you would configure.

    With our evaluation boards, we have Ethernet PHYs on all ports (including host port).

    For the PHY on Port 0 (host port) , this is hardware strapped to Auto-neg all speeds (10/100/1000). 

    If the link partner is a forced speed (auto-neg disabled), that results in "Parallel detect" and the link established will be Half Duplex. 

    This may not be what you want/intend and depending on what you are doing when testing our evaluation board, may skew behaviour, throughput etc. 

    In your setup, please ensure Auto-neg is enabled, the PHYs should bring up the highest common link speed (and the switch host port strapping should be configured to match). If there's an issue with Link speed, then only Advertise 100FD. 

    Hope this helps,

    Best regards,

    Catherine. 

    Copilot did a quick summary of Parallel detect: 

    Parallel detection is an Ethernet PHY feature that allows a device with auto-negotiation enabled to establish a link with a device that has auto-negotiation disabled and is operating at a fixed speed.

    How it works

    When no auto-negotiation pulses are received, the PHY examines the incoming Ethernet signaling and can determine the operating speed of the link partner:

    • Detects 10 Mbps operation
    • Detects 100 Mbps operation
    • Cannot determine duplex mode

    As a result, the auto-negotiating device can bring the link up at the correct speed even though capability exchange did not occur.

    Duplex Limitation

    Because parallel detection cannot determine the link partner's duplex setting, the IEEE 802.3 standard requires the auto-negotiating device to default to:

    • Half duplex for the detected speed

    This can lead to a duplex mismatch if the far-end device is configured for full duplex.

    Example:

    • Device A: Auto-negotiation enabled
    • Device B: Forced 100 Mbps Full Duplex (auto-negotiation disabled)

    Result:

    • Device A detects 100 Mbps via parallel detection and defaults to 100 Mbps Half Duplex
    • Device B remains at 100 Mbps Full Duplex

    This duplex mismatch can cause:

    • Reduced throughput
    • CRC/frame errors
    • Retransmissions
    • Poor network performance

    Relationship to Gigabit Ethernet

    Parallel detection is primarily applicable to 10BASE-T and 100BASE-TX links.

    For 1000BASE-T, auto-negotiation is required to exchange parameters such as master/slave configuration and link capabilities. Therefore, Gigabit operation normally requires both link partners to participate in auto-negotiation.

    Best Practice

    To avoid duplex mismatches and ensure optimal operation:

    • Enable auto-negotiation on both link partners whenever possible.
    • If speed/duplex must be fixed, configure both ends identically.
    • Avoid forcing one side while leaving the other side in auto-negotiation mode.
  • Catherine:

    Thanks for additional insight, it all makes sense.  The BBB is a stand in while I explore the various features of the ADIN6310. The host I will be interfacing to also supports only 10/100M, so forcing everything to 100M is reasonable. We'll be sure to pay attention to this as we move forward.

    (deleted my other question - I see that I should look at the ses-tsn-configuration-app for additional capabilities)

    Thanks,

    -Steve

Before You Switch


Switching languages will make ADI Explorer unavailable. Resume your session by switching back to English and reopening ADI Explorer.