stlink: workaround serial bug with old ST-Link DFU

Old ST-LINK DFU returns an incorrect serial in the USB descriptor
 example for the following serial "57FF72067265575742132067"
  - the correct descriptor serial is:
    0x32, 0x03, 0x35, 0x00, 0x37, 0x00, 0x46, 0x00, 0x46, 0x00 ...
    this contains the length (0x32 = 50), the type (0x3 = DT_STRING)
    and the serial in unicode format.
    the serial part is: 0x0035, 0x0037, 0x0046, 0x0046 ... >>  57FF ...
    this format could be read correctly by 'libusb_get_string_descriptor_ascii'
    so this case is managed by libusb_helper::string_descriptor_equal
  - the buggy DFU is not doing any unicode conversion and returns a raw
    serial data in the descriptor:
    0x1a, 0x03, 0x57, 0x00, 0xFF, 0x00, 0x72, 0x00 ...
            >>    57          FF          72       ...
    based on the length (0x1a = 26) we could easily decide if we have to fixup the serial
    and then we have just to convert the raw data into printable characters using sprintf

example for an old ST-LINK/V2 standalone:
  before : 'W?rreWWB g'
  after  : '57FF72067265575742132067'
  => same as the displayed value in STM32CubeProgrammer

tested using these commands
  using the buggy serial
    -c "hla_serial \x57\x3f\x72\x06\x72\x65\x57\x57\x42\x13\x20\x67"
  using the computed serial
    -c "hla_serial 57FF72067265575742132067"

Change-Id: I1213818257663eeb8e76f419087d3127d0524842
Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: http://openocd.zylin.com/5396
Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>

0 files changed, 0 insertions, 0 deletions