Segger Port Devices Driver

Posted on  by 



With the J-Link connected to the system, you should see a J-Link Driver Install the WinUSB driver for it: Keep in mind that with this, it is not a ‘normal’ J-Link anymore, so it cannot be used. The package provides the installation files for SAMSUNG Mobile MTP Device Driver version 2.9.201.1018. In order to manually update your driver, follow the steps below (the next steps).

FIND is a free to use protocol for Embedded devices which makes it easy and fast to locate them in the LAN. FIND locates all embedded devices supporting discovery in fractions of a second. With less than 300 bytes of ROM and no RAM for the implementation, it can be easily implemented on any device with any TCP/IP stack. You are free to use FIND for anything, even commercial and closed source software.

Segger Port Devices Drivers

  1. 1.FIND - Fast Interoperable Network Discovery Protocol
  2. 2.FIND Discover - The FIND response collector
  3. 3.FIND command-line server
  4. 4.How to add FIND to your application
  5. 5.emNet client side implementation
  6. 6.Resource usage
  7. 7.Protocol specification
  8. 8.The protocol on the wire
  9. 9.J-Link support

FIND - Fast Interoperable Network Discovery Protocol

In today's networks, even simple questions regarding the reachability of a device are nearly impossible to answer. Especially headless devices like sensors, network printers and network attached storages are often not responsive.

New devices which have to request an IP address from a DHCP server to get reachable are an everyday scenario. In home networks the IP address will normally automatically assigned to each device which sends a request. Thereafter, the device is available on the network, but still not automatically reachable for the user. To connect to the new device you need at least its IP address or the device name if local name resolution protocols like NetBios or mDNS are supported. If the IP address and the device name are unknown, the simplest solution is often to check the administration panel of the router and search the list of distributed IP addresses. This is doable, but not user-friendly.

How easy could it be, if every device would simply send a response, if the user asks for the name and the IP address of each device in his network? Sounds simple and reasonable, but nevertheless it is not normal in today's networks.

SEGGER's FIND (Fast Interoperable Network Discovery) protocol is designed to fill this gap. It helps to collect the most important information of each target on the network, works on top of each TCP/IP stack and helps to satisfy the needs of the normal user.

The simplest way to display the collected information is our free tool FIND Discover. It sends queries and lists all valid responses of the devices in the network.

FIND command-line server

To test FIND in your network, you can download a simple command line implementation of a FIND server, which generates and sends valid FIND responses with the information of your host. The application opens the UDP port 50022 and waits until it receives a valid FIND query. A FIND response will be send back after the receipt of a FIND query.

Download Sample command-line FIND server for Microsoft Windows hosts.

The protocol can be used on every hardware and with every TCP/IP stack.
If your device can send UDP packets, it can also add support for the FIND protocol.

Client side:

  • Open UDP port 50022 in listening mode.
  • Send a response to UDP port 50022 back to the query sender (unicast)

Host side:

  • Open UDP port 50022 in listening mode.
  • Send a FIND query (UDP broadcast to port 50022) with payload FINDReq=1;.
  • Check for responses sent by the devices with FIND support in the network.

emNet client side implementation

The code is for the client side is really simple. The sample implementation uses the emNet UDP zero-copy API.

Add it to your emNet application: Download the archive and add the included files to your project. To enable FIND support on your device, IP_FIND_Init() has to be called in your application. That's it. Thereafter your device will answer FIND queries and can be found in your network.

Download Sample implementation of the client side for emNet

Compiler settings:

CPU:

ROM usage:

The protocol is simple and efficient. A host sends a query via UDP broadcast to port 50022 and all clients which are listening on that port send a UDP unicast response with the used address configuration to port 50022.

  • The maximum size of the payload of FIND packets (query/response) is 512 bytes.
  • The payload of FIND queries and FIND responses is a zero-terminated UTF-8 string.
  • All printable characters except = , ; can be used in the string. The characters = , ; are used as delimiters.

Query payload: The payload of the query is a zero-terminated UTF-8 string, which will be checked by the listening devices. The string consists of the keyword FINDReq followed by the delimiter (=), the protocol version (1) and the delimiter (;). Optional type/value pairs (e.g. filter rules) can be added to the query. The payload ends with the zero-termination.

Response structure: The payload of the response is a zero-terminated UTF-8 string. The string starts with a marker which has to be checked by the device which receives the responses. The marker consists of the keyword FIND followed by the delimiter (=) and the protocol version (1). The marker ends with the delimiter (;). The marker is followed by type/value pairs. The sequence of the type/value pairs in the response string is not relevant.

Mandatory fields: The protocol specifies the following type/value pairs as mandatory:

  • Device name (e.g. DeviceName=MyTarget;)
  • Serial number (e.g. SN=12345678;)
  • Hardware address of the interface (e.g. HWADDR=00:22:CC:AA:BB:CC;)

Our sample implementation sends also the IP of the device as additional information.

  • IP address(es) of the interface (e.g. IP=192.168.123.123;)

The IP address of the device is always part of the IP header of response. If the IP address is not part of the response string, the client should extract the IP address out of the IP header of the packet.
Additional information can be added to the response (Type=Value;). Clients should ignore and skip unknown type/value pairs.

Devices with FIND support are listening on UDP port 50022. To get the information from each device with FIND support the host sends a UDP broadcast query with the query marker FINDReq=1 as payload to port 50022.

The devices with FIND support in the same network segment will receive the broadcast and check the payload for the query marker. If the marker is valid, each device will send an unicast response with the most important configuration settings as payload back to the host.

J-Link support

The industry leading SEGGER J-Link supports FIND since software version V6.34f. Use the free FIND Discover tool to detect the J-Link PROs in your network.

More Information

Purchase

Technology

Add-Ons

Tools

There are many different scenarios, which may prevent the J-Link from establishing a successful connection to the target device. The following article refers to the different scenarios and provides information on how to troubleshoot and in the next step how to fix them.In general, we recommend to verify the correct connection between J-Link and the target device using the diagnostic utility J-Link Commander before moving to the actual environment (e.g. Embedded Studio IDE). Therefore, this article refers to J-Link Commander and assumes that the latest J-Link Software and Documentation Pack (incl. J-Link USB driver) is installed. We recommend to work through this article from the beginning to the end.

  • 1J-Link connection
    • 1.1Connection is unsuccessful
  • 2Target connection
    • 2.2Connection is unsuccessful

J-Link connection

First, verify that the connection between the J-Link and PC is functional and J-Link Commander can communicate with the J-Link successfully:

  • Connect J-Link via USB to the PC
  • Start J-Link Commander
  • If the J-Link is functional, you should see that the J-Link Commander reports USB connection O.K. and outputs the firmware string:

Connection is unsuccessful

If the connection is unsuccessful, first check if the J-Link is listed in the Windows Device Manager. If it is not, you can skip the OpenOCD paragraph and continue with Test Conenction.

OpenOCD

For OpenOCD, a separate J-Link USB driver needs to be installed / used. If the OpenOCD J-Link USB driver is configured, J-Link can be used with OpenOCD but not with ordinary J-Link utilities like for example J-Link Commander. In order to be able to communicate with the J-Link in the native J-Link utilities, the driver needs to be switched back from the J-Link OpenOCD driver to the original J-Link USB driver.

Segger Port Devices Driver

Test Connection

  • Reboot the PC to make sure that the USB protocol itself is not in a confused state
  • Exchange the USB cable
  • Try a different USB slot
  • If a USB hub is used, remove it
  • Verify that the J-Link USB driver is installed
  • Switch to a different PC to exclude PC related issues

Make sure that you are not effected by the issues below:

If you followed the steps above and J-Link Commander is still not able to connect to the J-Link, please get in touch with SEGGER directly via our support system: https://www.segger.com/support/technical-support/. The message should include the answers to the questions below:
If you physically connect the J-Link to the PC via USB:

  • Is the green LED of the J-Link lit?
  • Does the Windows device manager show the J-Link in the list of USB devices?
  • Please send us a screenshot of the J-Link Commander while the J-Link is connected via USB to the PC.

Target connection

In general, we recommend to use an evaluation board to verify the correct functionality between the J-Link and the target device before moving to a custom hardware in order to exclude issues which might be caused by an incorrect hardware design.

Verify functionality using J-Link Commander

Please make sure that you are using the latest software version, available for download here: https://www.segger.com/downloads/jlink

  • Connect the J-Link via USB to the PC
  • Power the target device
  • Connect the target device with the J-Link
  • Start J-Link Commander and follow the startup configuration instructions

Connection is unsuccessful

In case of the connection is still unsuccessful, please follow the troubleshoot instructions below. If you are using an evaluation board and the issue persists after going through the instructions, , please get in touch with SEGGER directly via our support system: https://www.segger.com/ticket/.

VTref is 0.000V

J-Link measures 0V target reference voltage. As the target reference voltage is used by the J-Link to create the levels of the debug signals, the reference voltage is mandatory.

  • Check the power supply of the target hardware and verify that it is powered (switches on, jumpers are set correctly, etc...)
  • Measure the voltage between pin 1 (VTref) and pin 4 (GND) of the debug connector, using an multi-meter.

Interface settings

On some hardware / devices, only certain debug interfaces are connected and can be used. Another problem can be that the hardware does not allow higher interface speeds.

  • Check that the correct target interface is selected (JTAG, SWD, ...)
  • Reduce the interface speed to 100 kHz
  • For ARM926EJ-S cores, max. JTAG speed 1/8 up to 1/6 of the MCU speed (may be less then 100 kHz)

Interface signals

If the connection to the target still fails, there is most probably an problem with the interface signals themselves.Possible reasons:

  • Debug signals are not connected
  • Debug signals are shared with other peripherals / on board emulators
Device

Possible solutions:

  • Disconnect on board emulators or other peripherals which may interact on the target interface lines
  • Check the quality of the debug signals using an oscilloscope

After programming the target device, J-Link is no longer able to establish a connection

This can have different reasons as for example the application does disable the debug interface, re-configures the debug pins, enters some kind of low-power-mode or the security of the device is activated. In order to prevent such situations during the development process, we recommend to

  1. Add an delay of one second before the actual application code is executed. This allows the debug probe to reset the MCU and to halt it before the MCU executes the 'bad code' which would prevent the J-Link to establish a successful connection
  2. Select the correct device as this allows the J-Link DLL to perform special handling like for example halt in bootloader, connect under reset or unsecure device
Retrieved from 'https://wiki.segger.com/index.php?title=J-Link_cannot_connect_to_the_CPU&oldid=8608'




Coments are closed