I am using Seeedruino's XIAO module, and I would like to associate each XIAO with an unique ID. It seems each XIAO has its serial number, for example, when I plug one in different PCs, it shows a device instance path of USB\VID_2886&PID_802F&MI_00\6&DBB63AA&0&0000, with the same serial number(?) DBB63AA. How can I read this serial number?
For SAMD21-based boards, see section 10.3.3 of the datasheet:
10.3.3 Serial Number
Each device has a unique 128-bit serial number which is a concatenation of four 32-bit words contained at the following addresses:
Word 0: 0x0080A00C
Word 1: 0x0080A040
Word 2: 0x0080A044
Word 3: 0x0080A048
The uniqueness of the serial number is guaranteed only when using all 128 bits.
Note that this is a much longer serial number than is reported in the USB negotiation. I don't know whether the numbers are related.
There doesn't seem to be any symbolic definition for these memory addresses in any of the .h files And there is some question as to whether the fact that the words are not contiguous is reality, or an error in the datasheet
(For at least a while, Arduino AVR boards (Uno, Mega) were shipping with a serial number programmed into the EEPROM. Alas, that can easily be erased or reprogrammed, and hardly anything ever used it, and there are those clones to consider. I don't know whether this is still done. There is no documented unique serial number on those AVRs (Atmega328p, ATmega2560) (there has been some speculation that undocumented "signature byte" memory might contain such info, since the first AVRs that DOCUMENTED unique numbers described stuff like "wafer number", "die X coordinate", "die Y coordinate" that somewhat sounded like they might have been in other chips for a long time.)
What the "get board info" shows is almost certainly the serial number that is reported during USB enumeration. Who knows WHERE that comes from (on genuine Uno/Mega, it probably comes from the Atmega16u2 USB chip, which DOES have a unique serial number in signature bytes 0xE-0x18. However, if that's the number being reported, there isn't any way for the main CPU to read it!)
Ok, that number seems like it's fine. I can understand that it uses the number during USB enumeration as each different card I plug in wants a different COM port. But that number has to be coming from SOMEWHERE.
Can you CRC64 check the program and figure out a signature from that?