USBFS serial number changed?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
JoBr_1593366
Level 5
Level 5
100 sign-ins 50 questions asked 100 replies posted

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...

0 Likes
12 Replies
Aashita_R
Moderator
Moderator
Moderator
50 likes received 100 solutions authored 250 replies posted

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

0 Likes

Device is CY8C3446LTI-073

USBFS updated from 2.50 to 3.20

0 Likes
lock attach
Attachments are accessible only for community members.

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-

pastedImage_2.png

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

That's strange.  Mine is built in PC4.3 for both the "before" and "after":

v1.0.3 serial PC4.3.pngv1.0.3b 28505724 serial USBFS 2.60 PC4.3.png

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]

0 Likes

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.

PSoC3 serial numbers.png

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.

0 Likes

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

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

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.

0 Likes

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

Len
"Engineering is an Art. The Art of Compromise."

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.

0 Likes

JoBr,

Again.  Good questions.

I'm coming up empty.  I think Cypress needs to weigh in on this.

Len

Len
"Engineering is an Art. The Art of Compromise."

That silicon ID seems to be a part number, not a serial number

0 Likes

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

Len
"Engineering is an Art. The Art of Compromise."
0 Likes