CSEc code yields two different UID's?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

CSEc code yields two different UID's?

Jump to solution
2,252 Views
gearhead1107
Contributor IV

I'm trying to load crypto keys into my S32 using the example project "1_Configure_part_and_Load_keys", but the "GET_UID()" function yields two different results in the example vs my project on the same part (CSE_PRAM->RAMn[11].DATA_32 is different after the operation, so this seems to be an issue with the example)

The UID generated by the example is different only in the last byte - 21120833 vs 21120865 - while the upper 3 integers are identical, as shown in the two screenshots of the debug instances.

Interestingly, the driver function "CSEC_DRV_GetID" yields something totally different than the example.. is the example just incorrect?

I have attached screenshots of 

UID from the NXP example

{14, 1162432521, 909643814, 21120833}

UID from my project running NXP code 

{14, 1162432521, 909643814, 21120865}

UID from the Driver function which returned "STATUS_SUCCESS"

{edit - this output is erroneous due to some pointer incompatibility - it's the same as the above in RAM}

This is a 0N57U based eval board

Labels (1)
Tags (4)
0 Kudos
Reply
1 Solution
2,050 Views
gearhead1107
Contributor IV

It looks like the reason the example yields inconsistent results has to do with the fact "UID" is only 15 bytes. 
The example pulls in a full uint32, including the lower 16th byte, while the UID is *only* those upper 15.

If someone from NXP could confirm, it would be appreciated!

View solution in original post

0 Kudos
Reply
2 Replies
2,050 Views
tong_zhou
Contributor I

in mpc5777c manual, the UID's 8 lowest significance bits are set 0.

0 Kudos
Reply
2,051 Views
gearhead1107
Contributor IV

It looks like the reason the example yields inconsistent results has to do with the fact "UID" is only 15 bytes. 
The example pulls in a full uint32, including the lower 16th byte, while the UID is *only* those upper 15.

If someone from NXP could confirm, it would be appreciated!

0 Kudos
Reply