[stm32] use desig_get_unique_id from libopencm3

[flixr]

• update libopencm3 so we have desig in F4 lib
• use desig_get_unique_id_as_string from libopencm3 instead of our own function

[flixr]

@podhrmic this seems to work fine for me, would be great if you could cross check.

[flixr]

@podhrmic would be great if you could test this as well before we merge it...

[flixr]

Any chance that anyone else can test this? It works fine here, so I guess it is good to merge..
But would still appreciate if @podhrmic could take a look as well... (or just say if you won't have time soonish)

[podhrmic]

I ll look at it later today.

[benlaurie]

How does one test it?

On 16 December 2014 at 07:31, Michal Podhradsky notifications@github.com
wrote:

I ll look at it later today.

—
Reply to this email directly or view it on GitHub
#1018 (comment).

[flixr]

@podhrmic Ok, great
@benlaurie use telemetry type transparent_usb or the usb_tunnel and check if it correctly reports itself as CDC device with the chip serial number.

[podhrmic]

Tested, and I don't think it works:

Using this commit:

[94907.552977] usb 3-1: New USB device found, idVendor=1d50, idProduct=603d
[94907.552985] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[94907.552989] usb 3-1: Product: CDC Serial STM32
[94907.552993] usb 3-1: Manufacturer: Paparazzi UAV
[94907.552996] usb 3-1: SerialNumber: 736343335174332314009200

Using master:

[95455.216916] usb 3-1: New USB device found, idVendor=1d50, idProduct=603d
[95455.216923] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[95455.216927] usb 3-1: Product: CDC Serial STM32
[95455.216930] usb 3-1: Manufacturer: Paparazzi UAV
[95455.216933] usb 3-1: SerialNumber: 410029001547333237363433

The implementation in libopencm3 looks correct, and you can see that first four bytes (7363433) in desig ID are identical to last four bytes from get_dev_unique_id() but the rest is garbage - so my guess is that there is some alignment problem in libopencm3 version...

Or our implementation was always wrong?

[flixr]

It isn't gabage, just different odering, if you split the string into 3x8 chars (32bit each), reverse the order of the 3 blocks, then swap every char pair again, you get the same number.

Actually it seems that our implementation so far doesn't make that much sense...
The libopencm3 version "correctly" starts converting each nibble in the id (from MSB downwards) to a char that is added to a string. So it seems to me that the locm3 odering makes sense, while the one we had so far does not...

Also since in some STM series the memory location for the id is not contiguous and the function already handles these correcty I would vote for changing it to the loc3 version.

[flixr]

Updated to use the latest libopencm3 version that converts the high nibble of the id to hex char first:
libopencm3/libopencm3@f206fcb
Now desig_get_unique_id_as_string returns a string that corresponds directly to the id in hex...

[flixr]

Ah, yeah.. and also updated luftboot to use the libopencm3 function...