- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When comparing USB descriptors between versions, I noticed the serial number changed after updating the USBFS component. Is this documented somewhere? I don't see anything in the USBFS datasheet.
Previously it was 161409CB00218400, changed to 090500CB84211614, which sort of looks like a shuffling of the bytes but not exactly...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi JoBr_1593366,
I was trying to produce the issue on my end.
Can you please tell which device and which versions of USB component are you using?
Thanks and Regards,
Aashita
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Device is CY8C3446LTI-073
USBFS updated from 2.50 to 3.20
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi JoBr_1593366,
I have tried to run a project on CY8C5868AXI-LP035, where USB 3.20 and USB 2.60 components are used, one at a time in PSoC Creator 4.2. I have attached my project for your reference. I have kept the string descriptor same for both the components. In the Serial Number String under String Descriptor, Silicon Generated Serial Number was selected. The traces for USB 3.20 and USB 2.60 were compared as shown below-
The string descriptor for both the components turned out to be exactly same, as can be seen from the traces attached. Please go through the results and let us know in case of further clarifications. Also, I have attached the above comparison screenshot.
Best Regards,
Aashita
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's strange. Mine is built in PC4.3 for both the "before" and "after":
Components that changed at the same time and might have affected it:
cy_boot [v5.40] to [v5.90]
Bootloadable [v1.50] to [v1.60]
USBFS [v2.60] to [v3.20]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've gone through, version by version, and confirmed that the change happened in the transition from USBFS 2.80 to USBFS 3.0 and is not related to PSoC Creator version. The datasheet Component Changes section doesn't say anything about this.
Looks like it's from a change in USBFS_ReadDieID().
The old version reads the values out of registers in address order (not including REV). The new version uses the CyGetUniqueId() function.
But which number is actually correct? The UniqueID should be made of:
YR | FAB | WRK_WK | Y_LOC | X_LOC | WAFER_NUM | REV_ID | LOT_MSB | LOT_LSB
"Year: 0 to 9"
"Fab Number: 4 or 5"
"Work week: 1 to 53"
"Y location of die on the wafer"
"X location of die on the wafer"
"Wafer Number: 1 to 24"
REV? not listed in TRM?
"MSB of lot number/wafer start"
"LSB of lot number/wafer start"
So these aren't really in "big-to-little" order, right? The location on the wafer in the middle will change frequently while the wafer number and date at the ends will not?
In a run of units, I have IDs like:
DAFD381816083B00
DAFD3818180C3B00
DAFD381818113B00
DAFD38181A193B00
DAFD38181D213B00
DAFD381823093B00
DAFD381824113B00
So I would think the red parts are the Y_LOC and X_LOC, and then wafer number 0x81 and 0x82? But they don't seem to be in the correct position in the string, so the current USBFS 3.x components are not correct?
For the 09040367141B1427 chip, I confirmed these values:
CYREG_FLSHID_CUST_TABLES_LOT_LSB 0x67
CYREG_FLSHID_CUST_TABLES_LOT_MSB 0x03
CYREG_MLOGIC_REV_ID 0x04
CYREG_FLSHID_CUST_TABLES_WAFER_NUM 0x09
CYREG_FLSHID_CUST_TABLES_X_LOC 0x27
CYREG_FLSHID_CUST_TABLES_Y_LOC 0x14
CYREG_FLSHID_CUST_TABLES_WRK_WK 0x1b = week 27?
CYREG_FLSHID_CUST_TABLES_FAB_YR 0x14 = year 1?, fab 4
whereas the chip marking says
CY8C3446LTI-0
73 1201
C 04 PHI
CYP 602108
□
So I'm still pretty confused. The datecode is 1201 = 2012 week 1? Not sure how that corresponds to the year 1, week 27 inside the chip.
Fab site 4 matches, at least.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
JoBr,
Looks like it's from a change in USBFS_ReadDieID().
The old version reads the values out of registers in address order (not including REV). The new version uses the CyGetUniqueId() function.
Good detective work!
CyGetUniqueId() should be the 'official' way to get the Silicon ID. Sadly, when you installed your USBFS devices under Windows using the older USBFS component, the Windows registry most likely has the Silicon ID as a serial number under the 'old' way.
When you now use your USBFS devices under the new USBFS component, it probably recognized it with a different Silicon ID and loaded another enumerated value into the registry.
This means you have two registry entries for the same physical HW (but different Silicon IDs).
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
LePo_1062026 wrote:
CyGetUniqueId() should be the 'official' way to get the Silicon ID.
Ok. I just want to make sure it's being sent over USB in the correct order, though. In my examples above, if the OS sees a serial number string of "09040367141B1427", then that's correct? (As opposed to "27141B14..." or something like that.)
LePo_1062026 wrote:
Sadly, when you installed your USBFS devices under Windows using the older USBFS component, the Windows registry most likely has the Silicon ID as a serial number under the 'old' way.When you now use your USBFS devices under the new USBFS component, it probably recognized it with a different Silicon ID and loaded another enumerated value into the registry.
This means you have two registry entries for the same physical HW (but different Silicon IDs).
That's fine. From developing USB devices, I always have dozens of entries and delete them regularly. Customers won't see more than one entry per device.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
JoBr,
Ok. I just want to make sure it's being sent over USB in the correct order, though. In my examples above, if the OS sees a serial number string of "09040367141B1427", then that's correct? (As opposed to "27141B14..." or something like that.)
Good question. I asked Cypress a similar question. Not sure I got a solid answer. They said if PSoC came in for FAE, they would read it themselves during the analysis.
What silicon ID comes up in PSoC programmer?
Theoretically if the issue is that the Serial number (Silicon ID) needs just to be unique, what difference does the byte order make?
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
LePo_1062026 wrote:
What silicon ID comes up in PSoC programmer?
Where do you find that? That would be pretty authoritative.
In "Select Debug Target" it shows a silicon ID of 0x1E049069, while the USBFS reported ID is 0x09040367141B1427, so those seem unrelated.
LePo_1062026 wrote:
Theoretically if the issue is that the Serial number (Silicon ID) needs just to be unique, what difference does the byte order make?
Yes, but it's changed now, and I want to make sure it doesn't change again.
Also would just like to understand why the marks on the chip don't match the numbers in the chip.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
JoBr,
Again. Good questions.
I'm coming up empty. I think Cypress needs to weigh in on this.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That silicon ID seems to be a part number, not a serial number
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
JoBr,
You are correct.
Here's a snippet from the USBFS datasheet:
Silicon Generated Serial Number – This number is generated from the die ID of the silicon. The die ID is applied to non-volatile memory in the device at manufacturing time and it is not guaranteed to be unique.
If this option is selected, the Serial number is generated from the silicon ID but it is probably not directly the silicon ID. It probably goes through a transform function to produce the Serial number.
Len
"Engineering is an Art. The Art of Compromise."