PyOCD incorrectly truncates device Serial Numbers starting with '0'

[thegecko]

Serial Numbers can begin with zeros, in our investigation into this it's common for JLINK devices to have serial numbers of this form:

• 000820102635
• 000682561275

Listing devices with PyOCD seems to truncate these serial numbers and removes the leading zeros (mbed-ls lists them correctly).

This has a knock-on effect that when specifying a device uid for an operation, the device isn't found even though a valid serial number is passed. e.g.:

> pyocd flash --uid 000820102635 ...

[flit]

It looks like this is baked into the J-Link SDK API, which uses an int for the serial number instead of a string. If you notice in a tool like µVision or IAR, the serial numbers don't have the leading zeros (this is from memory, so I could be wrong!).

However, if we're certain that J-Link serial numbers are always 12-characters long, then the SN can be formatted as a string with leading zeros inside pyOCD for matching.

[flit]

Notice that the Segger tools all present the serial number without leading zeroes. This is from JLinkConfig.app:

[klgsnd]

Hi guys,
I'd like to bump up this issue. The same situation: my jlink probes have leading zeroes in their id's, e.g.

$ dmesg
...
[38141.592962] usb 1-1.2: Product: J-Link
[38141.592963] usb 1-1.2: Manufacturer: SEGGER
[38141.592964] usb 1-1.2: SerialNumber: 000261002616

When I try to create a session with the probe by providing unique_id it fails

Traceback (most recent call last):
  File "xxx/venv/lib/python3.8/site-packages/pyocd/probe/jlink_probe.py", line 168, in open
    self._link.open(self._serial_number_int)
  File "xxx/venv/lib/python3.8/site-packages/pylink/jlink.py", line 723, in open
    raise errors.JLinkException('No emulator with serial number %s found.' % serial_no)
pylink.errors.JLinkException: No emulator with serial number 261002616 found.

[flit]

@dnsglk How are you specifying the serial number on the pyocd command line? There may be two separate issues here. The JLinkException error is interesting since it doesn't include leading zeroes.

I just tested on macOS that using (for my nRF5340-DK) -u 960177309 or any unique subset of the serial number works fine. Leading zeroes aren't currently supported because the J-Link driver itself does not use leading zeroes, as evinced by the JLinkConfig screenshot above. It's apparently only the USB device serial number that has leading zeroes.

I'm wondering if there's a difference in behaviour between OSes.

[klgsnd]

@flit I'm doing it programmatically (on linux). Take a probe from the list obtained via API and use in another API call. Roughly:

probes = ConnectHelper.get_all_connected_probes()
with ConnectHelper.session_with_chosen_probe(unique_id = probes[0].unique_id) as session:
   ...

Probe's id in command line call:

❯ pyocd list
  #   Probe               Unique ID  
-------------------------------------
  0   Segger J-Link EDU   261002616  

[flit]

Ok, thanks. I'll replicate that and test on both Mac and Linux.

(Glad to see you're using the API, btw!)