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.

TM4C129ENCPDT: Clarification needed, UNIQUEID0 through UNIQUEID3 registers

Part Number: TM4C129ENCPDT

A few questions on the TM4C129ENCPDT device's unique ID registers (UNIQUEID0 through UNIQUEID3)

I understand that these are not random values. Are they sequential or is there some distribution across all 128 bits? If sequential, which word contains the least significant bits (the bits most likely to be different from part to part)? If not sequential, can we expect differences in all four words across different parts?

The datasheet gives only this explanation: "These registers contain a unique 128-bit identifier that cannot be modified by the user. This value is unique to each individual die but is not a random value. This unique device identifier can be used to initiate secure boot processes or as a serial number for USB or other end applications." (Datasheet dated June 18, 2014, section 5.5, registers 182 through 185.)

The reason for this question is that software needs to provide a unique MAC address for Ethernet communications. In the example programs, these numbers were stored in USER0 and USER1. If either register is not programmed (contains 0xffffffff) then the example programs enter a while(1) trap. For production purposes we'd like to fall back on something a bit more robust. One possibility is to grab six bytes of the UNIQUE ID. Another possibility is to generate random numbers and then persist them in FLASH or EEPROM. The problem with random numbers generated by srand()/rand() is that we are likely to get identical results on multiple parts, which will cause a network conflict. We would investigate using the chip's crypto accelerator hardware to generate random numbers. But the UNIQUE ID solution is by far the simplest.

  • twelve12pm said:
    A few questions on the TM4C129ENCPDT device's unique ID registers (UNIQUEID0 through UNIQUEID3)

    These questions have popped up before. A search may find. But the answer to your questions is basically; it's exactly as documented, no more or less.

    twelve12pm said:
    Are they sequential

    No

    twelve12pm said:
    If not sequential, can we expect differences in all four words across different parts?

    If you mean are all four words guaranteed to change. Not according to the documentation.

    The only performance guarantee TI was willing to make was that the numbers would be unique.

    Note that non-random and deliberate pattern are not the same.

    twelve12pm said:
    The reason for this question is that software needs to provide a unique MAC address for Ethernet communications. In the example programs, these numbers were stored in USER0 and USER1. If either register is not programmed (contains 0xffffffff) then the example programs enter a while(1) trap. For production purposes we'd like to fall back on something a bit more robust. One possibility is to grab six bytes of the UNIQUE ID

    As an end user I would consider that less robust. I'd prefer the device to fail outright rather than possibly corrupt the network

    Robert

  • Robert Adsett said:

    If you mean are all four words guaranteed to change. Not according to the documentation.

    The only performance guarantee TI was willing to make was that the numbers would be unique.

    Note that non-random and deliberate pattern are not the same.

    twelve12pm
    The reason for this question is that software needs to provide a unique MAC address for Ethernet communications. In the example programs, these numbers were stored in USER0 and USER1. If either register is not programmed (contains 0xffffffff) then the example programs enter a while(1) trap. For production purposes we'd like to fall back on something a bit more robust. One possibility is to grab six bytes of the UNIQUE ID

    Robert

    Thank you for your reply.

    In our application, without a network connection it will not be possible to know what went wrong. Generally speaking the equipment has its own internal network with router, etc. The user interface is one device on this network. Even to print an error message, we need a network connection to determine what the error is. So in this case, simply failing is not an option. We "just" need to make sure it has a MAC address in case something happens to USER0, USER1. I am thinking that the best solution is some sort of 48-bit hash of the longer 128-bit UNIQUE ID. Yes, with all hash functions there are collisions, but if we pick a good hash algorithm, and if we make sure that we ship the silly things with USER0, USER1 programmed correctly, so that they shouldn't fall back on this code in the first place, then the probability of encountering a MAC address collision within the equipment's network should be extremely low.

  • twelve12pm said:
    In our application, without a network connection it will not be possible to know what went wrong.

    No LED? Generally you need a method of signalling in the event your communication fails.

    twelve12pm said:
    Generally speaking the equipment has its own internal network with router, etc. The user interface is one device on this network

    The kind of network I use, although we generally move to CAN for control networks. We still have our LEDs though.

    twelve12pm said:
    Even to print an error message, we need a network connection to determine what the error is.

    Is the absence of the device from communication not a pretty strong indication that there is an issue?

    twelve12pm said:
    So in this case, simply failing is not an option. We "just" need to make sure it has a MAC address in case something happens to USER0, USER1.

    Be wary of such needs. I expect the ethernet interface failing is a higher probability than the MAC registers being overwritten. You are patching an unlikely failure mode with a fix that is unlikely to cause the entire network to fail.

    twelve12pm said:
    I am thinking that the best solution is some sort of 48-bit hash of the longer 128-bit UNIQUE ID.

    Better, since you are behind a router, would be to pick from the reserved private set of MACs, or from a subset of your reserved MACs. I dislike the robustness of either solution.

    twelve12pm said:
    Yes, with all hash functions there are collisions,

    The problem isn't the hashes collision with itself, the problem is the collision with the existing MAC allocations. If you are OK with that risk, just pick out of one of the pools earlier noted, it's still a small risk.

    twelve12pm said:
    but if we pick a good hash algorithm,  ... then the probability of encountering a MAC address collision within the equipment's network should be extremely low.

    I expect the nature of the hash has very little effect on the probability.

    Robert

  • Hi,
    Sorry to jump in between a good conversation between you and Robert. I'm not too clear if you are trying to grab six bytes of the unique ID for your MAC address. Please note that the MAC address must come from the pool of allocated MAC address to the organization/company and can not be any random numbers you desire.
  • Charles Tsai said:
    Hi,
    Sorry to jump in between a good conversation between you and Robert. I'm not too clear if you are trying to grab six bytes of the unique ID for your MAC address. Please note that the MAC address must come from the pool of allocated MAC address to the organization/company and can not be any random numbers you desire.

    MAC addresses have a U/L bit that identifies them as either "universally administered" or "locally administered." To make a locally administered MAC address, bitwise OR the MAC address with 02-00-00-00-00-00.

  • Hi,
    What about the LSB of the first octet of the MAC address if you need to distinguish between grouping address (broadcast or multicast) vs. individual address (unicast).
  • Charles Tsai said:
    Hi,
    What about the LSB of the first octet of the MAC address if you need to distinguish between grouping address (broadcast or multicast) vs. individual address (unicast).

    Good point. We have to bitwise AND with 01-00-00-00-00-00.

    I would imagine that the network stack should handle that bit automatically depending on whether a unicast or multicast packet is being sent, but it is quite possible that the minimal network stacks used in embedded systems do not offer every feature.

  • Robert Adsett72 said:
    twelve12pm
    So in this case, simply failing is not an option. We "just" need to make sure it has a MAC address in case something happens to USER0, USER1.

    You're right. It is an unlikely failure mode. Still, I don't like it when things just silently fail for no good reason. One of my pet peeves is coming in on a Monday and things that were working perfectly on Friday suddenly won't power up "for no reason." If there's a problem, I want the system to try really hard before it gives up, if only so that it can report what its problem is in a clear manner.

  • twelve12pm said:
    One of my pet peeves is coming in on a Monday and things that were working perfectly on Friday suddenly won't power up "for no reason." If there's a problem, I want the system to try really hard before it gives up, if only so that it can report what its problem is in a clear manner.

    I understand. But you do already have a perfectly good indication of the failure. The board is not communicating, surely your communications centre/HMI is aware of that? If it isn't aware, why not?

    In exchange for replacing a not communicating message with an I'm failed message you increase your development effort and the risk of creating further problems. And note that this partial recovery method only applies to a fraction of the communications losses and the less likely fraction at that.

    Robert