serialNumber does not return expected result


I am trying to use the serial number to identify multiple wixels communicating via RF. According to the SDK, it is defined as uint8 CODE serialNumber [4]. I use the following code to display this ID via the serial port:

reportLength = sprintf((char*)report, "Wixel ID: %02X-%02X-%02X-%02X \r\n", serialNumber[0], serialNumber[1], serialNumber[2], serialNumber[3]);
usbComTxSend(report, reportLength);

For 3 wixels tested, serialNumber[0] seems to return the correct first byte (and it corresponds to the first byte displayed in the wixel configuarion utility), but [1], [2] and [3] always returns 0, 0, 0x18 and this does not correspond to the last 3 bytes in the wixel configuration utility.

What is the correct way of successfully reading all 4 bytes of the Wixel’s internal serial Number?


you’re ahead of me!

I can’t even get the code to printf reliably

can you share your code so i can see what I missed
I’ll even see if I can sort out your serialNumber problem in exchange!

ok update on above
finally got printf working :slight_smile:

and I’m getting the same results as you
first hex pair correct , then 0-0-18

v odd

what is interesting is the file fixed.s
it’s not very large:

; This file contains the addresses of certain pieces of information that are
; stored the Wixel’s bootloader.

.module delay
.area CSEG (CODE)

.globl _serialNumber
.globl _serialNumberStringDescriptor
.globl _bootloaderDeviceDescriptor

;; The USB device descriptor of the bootloader is stored at this address:
_bootloaderDeviceDescriptor = 0x03CC

;; The four bytes of the serial number are stored in the bootloader at this address:
_serialNumber = 0x03E3

;; The Serial Number String Descriptor is stored in the bootloader at this address:
_serialNumberStringDescriptor = 0x03E6

the two entries in bold are unusual
if the serialNumber is indded 4 bytes, surely it would occupy 0x3E3 to 0x3E6 inclusive
but serialNumberDescriptor start at 0x3E6

maybe that explains why we keep getting 0x16, maybe serialNumberDescriptor is a pointer!
I suspect that serialNumber may be somewhere else
hmm wonder if it’s big-endian and finishes at 0x3E3?

haven’t worked out how to read bootloader memory (yet!)

You’re definitely on to something with the Big/Small endian! I managed to get the right serial number, going the other way in memory
This is what I’ve done:

	uint8* wixelID;
	wixelID = 0x03E0;

	 reportLength = sprintf((char*)report, "Wixel ID %02X-%02X-%02X-%02X\r\n", wixelID[3], wixelID[2], wixelID[1], wixelID[0]);
	 myusbComTxSend(report, reportLength);

so as you say the SerialNumber ENDS at 0x3e3, so by starting my array at 0x03e0 and going backwards, I managed to get the right ID.


Hello. Thank you for uncovering a bug in the Wixel SDK!

The line that defines the address of the serial number in fixed.s was wrong. It should be 0x3E0 because that is the start address of the serial number. That address is documented in the “The Wixel USB Bootloader” section of the Wixel User’s Guide. You can download the latest version of the Wixel SDK from github to get a fixed version of that file, or just fix it yourself.


… and note that the ID is “backwards” too!

Hello, mmcp42,

I agree that the way the serial number is stored might seem “backwards” if you think of it as an array of four 8-bit bytes. It might help to think of it as a single little-endian 32-bit number instead, so that byte 3 contains the most significant 8 bits and byte 0 contains the least significant 8 bits. In retrospect, it might have made more sense for us to define serialNumber as a uint32 instead of a uint8 array.

- Kevin

I only mention it as I guess most people (ok me) would expect
wixelID[0] to wixelID[3] to show the ID rather than
wixelID[3] to wixelID[0]
not a big deal, the info is there - that’s what matters
I’ve updated my SDK document