This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28377D: Fletcher Checksum with UID

Part Number: TMS320F28377D

Hi,

My customer did the  Fletcher Checksum with UID,

But the results told us that some chips using big endian mode , and others using little endian mode.

Could TI explain which mode using in F28377D?

Or any wrong code with below calculate algorithm program?

device 1 UID:

uint16_t UID_Data1[]={0x2c6d ,0x81b9 ,0x1656 ,0x472e ,0x4899 ,0xfa9a ,0x4e7f ,0x9e3b ,0x51a8 ,0xda30 ,0x2ca5 ,0xcb9e ,0x0008 ,0x64e5 ,0x33c2 ,0xc4a4};

uint16_t UID_Data2[]={0x81b9 ,0x2c6d ,0x472e ,0x1656 ,0xfa9a ,0x4899 ,0x9e3b ,0x4e7f ,0xda30 ,0x51a8 ,0xcb9e ,0x2ca5 ,0x64e5 ,0x0008 ,0xc4a4 ,0x33c2};

calculate result:

UID_CRC1       unsigned long  0x4804C4A4 (Hex)         

UID_CRC2       unsigned long  0x33C2C4A4 (Hex)        

device 2 UID:

uint16_t UID_Data3[]={0x9dc8 ,0x289b ,0x3e8e ,0xc11b ,0x3e8c ,0xbff4 ,0xe00e ,0xea60 ,0xbbb3 ,0xc382 ,0x930c ,0x1b7d ,0x0077 ,0xd980 ,0x3929 ,0x96b6};

uint16_t UID_Data4[]={0x289b ,0x9dc8 ,0xc11b ,0x3e8e ,0xbff4 ,0x3e8c ,0xea60 ,0xe00e ,0xc382 ,0xbbb3 ,0x1b7d ,0x930c ,0xd980 ,0x0077 ,0x96b6 ,0x3929};

 calculate result:

UID_CRC3       unsigned long  0x392996B6 (Hex)         

UID_CRC4       unsigned long  0x36C596B6 (Hex)         

calculate algorithm program as below:

--------<declare>--------------------------------------

uint32_t fletch32(uint16_t const * pu16Data, uint32_t length, uint32_t seed);

// UID 0x000703C0  ==>93EEBC4E   5C64CAE9    7597B4B0    4DF20580    0B333C18    650D013C    000D1F39    62E7C220

uint16_t UID_Data2[]={0xBC4E ,0x93EE ,0xCAE9 ,0x5C64 ,0xB4B0 ,0x7597 ,0x0580 ,0x4DF2 ,0x3C18 ,0x0B33 ,0x013C ,0x650D ,0x1F39 ,0x000D ,0xC220 ,0x62E7};

uint32_t UID_CRC=0,seed = 0xFFFFFFFF;

 

-----<main()>-----------------------------

    UID_CRC=fletch32(UID_Data2,14,seed);

 

------<function>---------------------------------------------

//seed = 0xFFFFFFFF;

uint32_t fletch32(uint16_t const * pu16Data, uint32_t length, uint32_t seed)

{

uint32_t u32Sum1 = 0xFFFFU & seed, u32Sum2 = 0xFFFFU & (seed >> 16U);

uint16_t u32Index, idx;

uint16_t data;

 

for(u32Index=0U;u32Index < length; u32Index++)

{

idx = u32Index^1; // little endian mode otherwise use u32Index only

data = pu16Data[idx];

u32Sum1 += data;

u32Sum1 = (u32Sum1 >> 16U) + (u32Sum1 & 0xFFFFU);

u32Sum2 += u32Sum1;

u32Sum2 = (u32Sum2 >> 16U) + (u32Sum2 & 0xFFFFU);

}

return ( (u32Sum2 << 16U) | u32Sum1);

}

best regards,

Simen

  • Hi Simen,

    The algorithm you shared seems fine. I was able to use it on a few devices without issue. It should all be little endian.

    Can you get a memory dump of addresses 0x703c0 to 0x703ce for these devices? Something like a snapshot of the CCS Memory Browser in "32-Bit Hex - TI Style" should work.

    Whitney
  • Any progress? Were you able to get the requested memory dumps?

    Whitney
  • Whitney,

    I have gotten memory dump as below picture from customer:

    ---------------------------------------------------

    uint16_t UID_Data1[]={0x375F ,0x700B ,0x8EA3 ,0x4907 ,0x8758 ,0x73F1 ,0xE781 ,0x50BC ,0x7949 ,0xC2EE ,0xCC1A ,0x6E42 ,0xD3D9 ,0x0008 ,0xFD14 ,0x831B };

    uint16_t UID_Data2[]={0x700B ,0x375F ,0x4907 ,0x8EA3 ,0x73F1 ,0x8758 ,0x50BC ,0xE781 ,0xC2EE ,0x7949 ,0x6E42 ,0xCC1A ,0x0008 ,0xD3D9 ,0x831B ,0xFD14 };

     

    uint16_t UID_Data3[]={0xD319 ,0x5A4B ,0x5793 ,0x1729 ,0x6223 ,0xD3FF ,0xB608 ,0xD919 ,0xC461 ,0xF515 ,0xBB53 ,0xCF87 ,0xD9C3 ,0x0077 ,0x7FF5 ,0x97E1 };

    uint16_t UID_Data4[]={0x5A4B ,0xD319 ,0x1729 ,0x5793 ,0xD3FF ,0x6223 ,0xD919 ,0xB608 ,0xF515 ,0xC461 ,0xCF87 ,0xBB53 ,0x0077 ,0xD9C3 ,0x97E1 ,0x7FF5 };

     

    UID_CRC1       unsigned long  0x831BFD14 (Hex)         

    UID_CRC2       unsigned long  0x223DFD14 (Hex)         

    UID_CRC3       unsigned long  0xDF317FF5 (Hex)         

    UID_CRC4       unsigned long  0x97E17FF5 (Hex)         

    -------------------------------------------------------

    little endian:

    big endian:

    best regards,

    Simen

  • Hi Simen,

    We are currently looking into this. In the meantime, could you also please take a 32-bit dump on these 2 locations:

    0x5D076
    0x5D078

    Thanks and regards,
    Joseph
  • Joseph,

    My customer had sold out the product.
    They will filter the wrong product and dump the 2 locations in the next time manufacture .
    Besides dumping the 2 locations, any other location or thing should be concern ?
    thanks,


    best regrads,
    Simen
  • Hi Simen,

    No, those two locations should be sufficient.  By the way, can you tell me how your customer uses the checksum for the unique ID fields?  Is the application requiring all 6 32-bit  random ID locations + 1 32-bit Unique ID + 1 32-bit checksum?

    Thanks and regards,

    Joseph

  • Hi Simen,

    Checked the history of the checksum routines that are used for the UID and learned that both methods of calculation (little and big endian) are acceptable so both devices described above are good. For the F2837xD/2837xS/2807x family, the checksum for UID was initially done in little endian mode and has switched to using big endian at a later time. We will update the Technical Reference Manual that describes how the UID checksum is calculated.

    Sorry for the confusion.

    Best regards,
    Joseph
  • Joseph,

    Thanks for your detail answer.
    I will deliver this message to customer.

    best regards,
    Simen