TM4C129XNCZAD: Automated production of MAC addresses and serial number

Bear in mind that I haven't used it, but Segger supports writing a unique serial number to memory. As well this could be leveraged to update the MAC address of the micro since you can do that from the user application.

Segger may also have other support mechanisms for writing the user registers but I haven't checked with them.

Robert

Peter Borenstein said:

I'm very surprised there aren't more straightforward answers...

I'm not. These tools are not TI's primary product and semiconductor vendors do not have an especially great track record in this regard.

Robert

Peter, Ralph,

Regarding the programming of the MAC Address, I believe this justifies a bit more of customized software for acquiring the values from a remote location, and writing it to the product's MCU, possibly during the test phase. It seems unlikely that a product with a MAC address won't have some sort of serial communication port, and that would be a convenient path for this number to get transferred... This automation seems beyond "just a script in the programming (Uniflash) solution)", for it will require some sort of feedback to wherever the allocated pool is stored in the company... How to avoid reallocating mac addresses accidentally, right?

Now, as for the Unique Id, I have to express my flabbergastness! So many years with Tivas, since LM and XM part numbers, and I had not known of such registers. Being them "Register 182...", might I believe my attention of reading the summary of a datasheet had faded some lines before? Interestingly enough, not only I posted long ago a question related to how to uniquely identify a product, but in other posts I also suggested the part number of an eeprom we apply in our products to get a 128-bit UID, and never such comment came up! Wow.

Ralph, is the 128-bit content of UNIQUEID0-3 indeed that: a unique Id across the whole TM4C family? Does this uniqueness extend out to other TI devices that you are aware of?

Regards

Bruno

Hi Ralph,

Thanks for replying! The mentioning of the fact that the 123x family does not have the Id feature is also a relevant point.

This "unique id" theme is probably a recurring discussion among developers, and possibly one with no definitive solution... Such as mac addresses have a regulating board to allocate pools, there should exist (maybe there is, I never searched that deep) a real "worldwide unique id" for hardware... I'd say 128bits are still enough for "any active processing device to be ever built" - but even that statement is risky in these Moore times.

Just to share the status, in our case we shall remain using an external small, low cost eeprom IC that comes with a 128bit UID. It is "our chosen way" to uniquely identify a product of ours. But at least having learned about the 129x feature, it won't hurt to trace that as well, when there's some boring time available for a small library - or suggest it for colleagues developing other products with the IC.

Cheers

Bruno

Thanks Peter, I wasn't aware of that. This statement

Peter Borenstein said:

"While the probability that a UUID will be duplicated is not zero, it is close enough to zero to be negligible"

only applies for one of the cases (the random generation case, the others rely on pre-existing unique values) and seems perhaps a touch optimistic.

What they consider negligible is that if (and these conditions are not small considerations)

• you can assume independent random number generation
• you can assume the random number generation is actually random**

then you have a 50% probability of duplication in 10¹⁸ generations***. That's a lot of numbers but it's also a very high probability. It virtually guarantees collisions once you reach that point. In fact I think you want to limit the population to a range such that the probability of collision was < say 1 part in 10⁶, maybe less. That's going to reduce the population of available numbers substantially although I'm not sure how much. Maybe an order of magnitude or two? Maybe more? That's a solvable problem if anyone wants to work it out.

As a proxy for how many numbers might be needed, consider the market for CPUs which according to wiki https://en.wikipedia.org/wiki/Microprocessor#Market_statistics has been recently at 10¹⁰ per year and growing. So depending on the likelihood of collision you are willing to accept the limitations of this technique are visible for use as a 'guaranteed unique' product identifier*.

The good news is that really the only requirement for a unique identifier is communications and that brings us back to the MAC number. Since it relies on assignment rather than random numbers a small number size can still guarantee uniqueness. I've seen suggestions that would remove even that requirement in the same way it's been removed for IP address. Not sure how that would be managed behind the 'router' though.

I think Bruno's approach is the only method that will work across products from multiple vendors for unique identifiers (if you can guarantee all of you products have MACs then that is an alternative) and I think I've seen a couple of suppliers for similar products. The problem is that you need all of your products to use the same IC from the same supplier. Mind you I've not seen anyone really require a serial number unique across the company for all products, only within a product or product line. And that reduces the problem considerably.

The good news is you could use this method to apply serial numbers to your products and it is only going to be an issue if you start approaching the current CPU production for a significant period of time. OTOH you could just assign serial numbers from a corporate pool (or use the ICs mentioned) and solve the problem in a much simpler fashion.

Robert

* by orders of magnitude 18-10 giving 10⁸ years at recent production rates and 8-2 for reducing the probability reduces that again to 10⁶. That's still a large number but increases in global production or desires for greater resistance to collision will reduce it even further. As will any imperfections in the random number generators. One item that would work in your favour is that most items have reasonably short lifetimes so their identifiers could return to the available pool.

** Pretty much by definition any PRNG will, at some level, be non-random.

*** This is out of a number space of 10³⁶ so you don't fill in much of the space before the likelihood of collision become high.

R.A. "The only way to guarantee uniqueness is to be non-random."

And the converse (perhaps), "Is only the guarantee of "randomness" - the result of being "unique?"

And I have always wondered about the BootP random seed generator embedded in the Stellaris Serial Boot Loader application. Code was written as if it could assign a MAC address from thin air to blank USER0/1 registers.  Not that it ever seemed to assign a random MAC to a erased M3 MCU or otherwise do anything useful after the boot loader was flashed.

What was the purpose for an random seed number generator, perhaps at one time thought ok within the confines of the private network not so regulated by RFC's as the Internet of late. Yet the  code seemingly could not register USER0/1 on erased M3 when the boot loader was flashed via JTAG and forget LM flash M4 easy method to update USER0/1 registers it didn't exist for the M3.

//*****************************************************************************
//
//! Computes a new random number.
//!
//! This function computes a new pseudo-random number, using a linear
//! congruence random number generator.  Note that if the entire 32-bits of the
//! produced random number are not being used, the upper N bits should be used
//! instead of the lower N bits as they are much more random (for example, use
//! ``RandomNumber() >> 28'' instead of ``RandomNumber() & 15'').
//!
//! \return Returns a 32-bit pseudo-random number.
//
//*****************************************************************************
static unsigned long
RandomNumber(void)
{
    //
    // Generate a new pseudo-random number with a linear congruence random
    // number generator.  This new random number becomes the seed for the next
    // random number.
    //
    g_ulRandomSeed = (g_ulRandomSeed * 1664525) + 1013904223;

    //
    // Return the new random number.
    //
    return(g_ulRandomSeed);
}


    //
    // If a static MAC address is not being used, then get the MAC address from
    // the flash user registers.
    //
#ifndef ENET_MAC_ADDR0
    ulTemp = HWREG(FLASH_USERREG0);
    g_sMACAddr.addr[0] = ulTemp & 0xff;
    g_sMACAddr.addr[1] = (ulTemp >> 8) & 0xff;
    g_sMACAddr.addr[2] = (ulTemp >> 16) & 0xff;
    ulTemp = HWREG(FLASH_USERREG1);
    g_sMACAddr.addr[3] = ulTemp & 0xff;
    g_sMACAddr.addr[4] = (ulTemp >> 8) & 0xff;
    g_sMACAddr.addr[5] = (ulTemp >> 16) & 0xff;
#endif

    //
    // Seed the random number generator from the MAC address.
    //
    g_ulRandomSeed = *(unsigned long *)(g_sMACAddr.addr + 2);

    //
    // Initialize the uIP stack.
    //
    uip_init();
    uip_arp_init();

    //
    // Program the MAC address.
    //
    HWREG(ETH_BASE + MAC_O_IA0) = *((unsigned long *)g_sMACAddr.addr);
    HWREG(ETH_BASE + MAC_O_IA1) = *((unsigned short *)(g_sMACAddr.addr + 4));
    uip_setethaddr(g_sMACAddr);