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
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
- 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
- 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'
Scroll to top
---|