USB_Device_GetSerialString Serial Number Nibble Question about lufa

[abcminiuser]

LUFA reads them out low nibble first, each nibble forming one hexadecimal digit of the serial number. The PC will them display that in MSB format, so a physical byte 0xDC will show on the PC as "DC". As the serial number is unique but opaque I though it didn't really matter how it was serialized out for the host as long as the algorithm was stable.

The device serial is effectively an internal ID code (wafer number, lot number, etc.) that is put in each device during manufacturing. I do not know the exact decoding - I didn't ask at Atmel so as not to taint my OSS efforts.

[jpliew]

Hi @abcminiuser ，

Thank you so much for your reply.

What I got is a physical byte 0x57 , read from boot_signature_byte_get(), is being sent as 75 by LUFA to the PC and displayed as 75 by device manager (or any USB info software) as seen from the screen capture.

If you breakpoint at the following code from Device_AVR8.h

uint8_t SerialByte = boot_signature_byte_get(SigReadAddress);

you can see that the SerialByte is not the same as the one PC received from LUFA because the HIGH nibble and LOW nibble are in different order.

I suppose as long as the serial number is UNIQUE, it should be ok. Having said that, if we implement the current method used by LUFA to display the DEVICE ID, which is a few address above the UNIQUE SERIAL NUMBER, the physical bytes of ATMEGA16U2's DEVICE ID is

0x1E 0x94 0x89

Using LUFA's method to read LOW nibble first, the result will be

E1 49 98

which is an invalid DEVICE ID.

Cheers
JP

[abcminiuser]

What I got is a physical byte 0x57 , read from boot_signature_byte_get(), is being sent as 75 by LUFA to the PC and displayed as 75 by device manager (or any USB info software) as seen from the screen capture.

That's correct - LUFA is backwards. I guess I didn't notice when I implemented it, and it's too late to change it now (it would change the serial number for all devices in the wild). That said, since it's an opaque byte stream as I mentioned, there's no harm done as long as all the bits are transmitted (since it will be a unique N-bit number either way).

If you want to implement this in your user code, you aren't bound to the same algorithm as the internal USB_Device_GetSerialString() function. You can swap the nibbles as you construct the USB string descriptor in RAM so that the most significant nibble is sent as the leading digit, rather than the other way around as used by the internal LUFA serial string construction function.

[jpliew]

Thanks @abcminiuser , appreciated your explanation, this clears up my question.

Keep up the good work.