#110 STLINK serial numbers with multiple adaptors on same PC

[Michael James]

OpenOCD 0.9.0 with STLINK does not handle serial numbers very well. These serial numbers are binary derived from an internal unique 96 bit CPU serial ID number.
They may contain 0x00 bytes WITHIN the serial numbers not only at the end of an ASCII string like other USB serial numbers. So using strncmp() as in OpenOCD code fails anyway by assuming that they are pure ASCII

The command hla_serial allows the user to define the serial numbers using escape sequences.
However the printing of the device serial numbers from within OpenOCD with debug level 3 does not allow the user to determine the correct string to enter into the hla_serial command. If you are French and using a French language Windows envirionment, for example, characters can be mapped so that it is impossible to determine the correct string to use ...

What I did was I changed the code, so that the serial number is printed out in the escaped form if a match is not found

as in attached patchfile.

While this may not be the best way to do it , it is useful

Here is a debug trace with my patch -

Line 259 shows usual STLINK junk serial number - this is the user input from hla_serial command..
Line 260,261 shows diagnostics from opening each device.

It can be seen from this that the correct commands are

"hla_serial S?r\x06exUU\x128\x04g"
for the first adapter and
"hla_serial S?p\x06exUUR7\x18g"
for the second adapter

In my example I deliberately garbled the hla_serial argument to make it enumerate all the serial numbers.

Debug: 258 104 stlink_usb.c:1602 stlink_usb_open(): stlink_usb_open
Debug: 259 104 stlink_usb.c:1619 stlink_usb_open(): transport: 1 vid: 0x0483 pid: 0x3748 serial: Sa?pexUUR7g
Debug: 260 160 libusb1_common.c:111 string_descriptor_equal(): Device serial number 'S?r\x06exUU\x128\x04g' doesn't match requested serial 'Sa?p\x06exUUR7\x18'
Debug: 261 162 libusb1_common.c:111 string_descriptor_equal(): Device serial number 'S?p\x06exUUR7\x18g' doesn't match requested serial 'Sa?p\x06exUUR7\x18'
Error: 262 163 stlink_usb.c:1632 stlink_usb_open(): open failed

[Paul Fertser]

Hello Michael,

Please see http://openocd.zylin.com/#/c/2343/ and leave feedback
there. It should cover your usecase, hopefully.

--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com

[Alain Mouette]

Hi Paul,

Do you have any idea how to cope with the same problem in VirtualBox (on
Linux)?

If I set the STLink in the USB filter to be allways available, the next
time I run VirtualBox the VM is invalid, it shows an erro about "invalid
character".
After some time I discovered that I can edit the .vbox file and remove
the line with the STLink device and fix it.

Thanks,
Alain

On 21-10-2015 16:16, Paul Fertser wrote:

Hello Michael,

Please see http://openocd.zylin.com/#/c/2343/ and leave feedback
there. It should cover your usecase, hopefully.

--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com

---

[tickets:#110] http://sourceforge.net/p/openocd/tickets/110/ STLINK
serial numbers with multiple adaptors on same PC

Status: new
Milestone: 0.9.0
Labels: stlink
Created: Wed Oct 21, 2015 12:39 PM UTC by Michael James
Last Updated: Wed Oct 21, 2015 12:39 PM UTC
Owner: nobody
Attachments:

• stlink-serial-gibberish.patch
  http://sourceforge.net/p/openocd/tickets/110/attachment/stlink-serial-gibberish.patch
  (2.0 kB; application/octet-stream)

OpenOCD 0.9.0 with STLINK does not handle serial numbers very well.
These serial numbers are binary derived from an internal unique 96 bit
CPU serial ID number.
They may contain 0x00 bytes WITHIN the serial numbers not only at the
end of an ASCII string like other USB serial numbers. So using
strncmp() as in OpenOCD code fails anyway by assuming that they are
pure ASCII

The command hla_serial allows the user to define the serial numbers
using escape sequences.
However the printing of the device serial numbers from within OpenOCD
with debug level 3 does not allow the user to determine the correct
string to enter into the hla_serial command. If you are French and
using a French language Windows envirionment, for example, characters
can be mapped so that it is impossible to determine the correct string
to use ...

What I did was I changed the code, so that the serial number is
printed out in the escaped form if a match is not found

as in attached patchfile.

While this may not be the best way to do it , it is useful

Here is a debug trace with my patch -

Line 259 shows usual STLINK junk serial number - this is the user
input from hla_serial command..
Line 260,261 shows diagnostics from opening each device.

It can be seen from this that the correct commands are

"hla_serial S?r\x06exUU\x128\x04g"
for the first adapter and
"hla_serial S?p\x06exUUR7\x18g"
for the second adapter

In my example I deliberately garbled the hla_serial argument to make
it enumerate all the serial numbers.

Debug: 258 104 stlink_usb.c:1602 stlink_usb_open(): stlink_usb_open
Debug: 259 104 stlink_usb.c:1619 stlink_usb_open(): transport: 1 vid:
0x0483 pid: 0x3748 serial: Sa?pexUUR7g
Debug: 260 160 libusb1_common.c:111 string_descriptor_equal(): Device
serial number 'S?r\x06exUU\x128\x04g' doesn't match requested serial
'Sa?p\x06exUUR7\x18'
Debug: 261 162 libusb1_common.c:111 string_descriptor_equal(): Device
serial number 'S?p\x06exUUR7\x18g' doesn't match requested serial
'Sa?p\x06exUUR7\x18'
Error: 262 163 stlink_usb.c:1632 stlink_usb_open(): open failed

---

Sent from sourceforge.net because openocd-devel@lists.sourceforge.net
is subscribed to http://sourceforge.net/p/openocd/tickets/

To unsubscribe from further messages, a project admin can change
settings at http://sourceforge.net/p/openocd/admin/tickets/options.
Or, if this is a mailing list, you can unsubscribe from the mailing list.

---

---

OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

[Spencer Oliver]

closed due to no recent activity - please reopen if this is still an issue.