System Reference Guide states clearly:
void CyGetUniqueId(uint32* uniqueId)
Returns the 64-bit unique id of the device
uniqueId: Pointer to a two element 32-bit unsigned integer array.
Returns the 64-bit unique id of the device by loading them into the integer array
pointed to by uniqueId
If the next question is: "What exactly is in the Unique ID", I got that info from tech support a while back:
Please find the details of 8bytes returned for CyGetUniqueId
Die Y position (0x49000100, y_loc[7:0])
Die X position (0x49000101, x_loc[7:0])
Die Wafer Number (0x49000102, wafer_num[7:0])
Die Lot number LSB (0x49000103, lot_lsb[7:0])
Die Lot number MSB (0x49000104, lot_msb[7:0])
Die production WW (0x49000105, work_week[7:0])
Die production year and fab (0x49000106, year[3:0], fab[3:0])
Die Minor Revision number (0x49000107, minor[7:0])
You can find this described in the register TRM as well or if you check the definition in PSoC Creator.
Thank you Bob,
I'm aware of the cyboot call.
Thank you Mike,
However, I don't think your supplied info matches the PSoC 5LP format based on the UniqueID example project.
Thank you Roy,
I downloaded the project example. It breaks down the 8 byte ID into Fab info.
As you can see by the archived project, I have no problem extracting the 64 bit uniqueID.
Theoretically, the number retrieved can be used by me in either form. I just need a unique number to coordinate among multiple instances of my product being used on the same computer.
My concern is if I needed to report the specific uniqueID to Cypress for some FAE issue, if the number is longword-order reversed, Cypress may have difficulty reverse-engineering the proper fab info.
Thank you Len.
the consistence of chips is guaranteed by factory QA.
For FA cases, we requires failure units sent back to review it.
So in this case, you don't need to mind if Cypress has difficulties on everse-engineering the proper fab info.
Thanks for the feedback.