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.

[参考译文] TM4C129XNCZAD:自动生成 MAC 地址和序列号

Guru**** 2446130 points
Other Parts Discussed in Thread: UNIFLASH, SEGGER

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/630422/tm4c129xnczad-automated-production-of-mac-addresses-and-serial-number

器件型号:TM4C129XNCZAD
主题中讨论的其他器件:UNIFLASHSEGGER

什么工具可以自动填写 MAC 地址和序列号的唯一部分?

开发套件将该 MAC 地址存储在用户寄存器0和1中。 我可以使用 UniFlash 读取该存储器的新地址并将其写入该存储器。 不幸的是、人类速度慢且容易出错、因此这种方法不适合制造。

Uniflash 因命令行而振奋人心。 闪存过程应该是执行测试并记录结果的脚本的一部分。 一个简单的接口适用于 python 脚本。

Uniflash 是否具有获取下一个有效数字格式文件并将其刷写到存储器区域(或将其注入.out 二进制文件)的某些功能? 我在文档中找不到任何类似的内容...

TI 已投入精力制造 TM4C 开发套件。 记录和共享此过程将是一个令人惊叹的资源。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Peter、

    好的、这个有两个部分(MAC 和序列号)、我将在这个帖子中单独回答它们。

    对于 MAC 地址、坦率的回答是、我们没有像 Uniflash 这样的工具那样的自动化过程。

    Uniflash 或 LM 闪存编程工具均可用于对 MAC 地址进行编程、以及将 MAC 地址刷写为编程到电路板中的初始应用的一部分。

    另一种可能是制作某种脚本、以自动执行使用 Uniflash 的过程(在另一个论坛帖子中作为建议、而不是我们所做的事情)。

    就我们 TM4C 开发套件的制造而言、对于 LaunchPad、MAC 地址从分配给 TI 的 MAC 地址池中分配。 这就是在发货前刷写电路板的方法。 因此、考虑到这一点、对于定制设计、MAC 地址必须来自分配给组织/公司的 MAC 地址池-这只是我认为您可能希望看到的一个常规重复注释。

    接下来、我们来看看序列号主题、您是指每个 TM4C 器件中编程的128位唯一标识符吗? 如果是、则无法修改。 或者是否有其他您要参考的序列号? 我看不到任何其他符合数据集描述的内容。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    请记住、我没有使用过它、但 Segger 支持向存储器写入唯一的序列号。 此外、还可以利用此功能来更新微控制器的 MAC 地址、因为您可以从用户应用程序中执行此操作。

    SEGGER 可能还具有其他用于写入用户寄存器的支持机制、但我尚未检查这些支持机制。



    Robert

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Ralph、

    您能否描述地址池中的数字到底是如何刷写到微中的? 您的员工是否使用 Uniflash 手动插入所有 MAC 地址、或者您是否遵循其他流程?

    我已经为我的公司分配了一个池。 我只需要知道如何以合理的方式将它们实际放入闪存中。

    序列号是由日期和其他一些东西生成的12位数代码。 我假设 MAC 地址编号的相同答案也适用于序列号。 如果您有某种方法在存储器中放置6个字节、它可能也适用于12个字节。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Robert、

    我将介绍 Segger。 制作 IP 设备的每个人都必须遇到此问题。 独特的序列化 ID 是嵌入式器件相当常见的硬件要求。 我很惊讶没有更直接的答案...
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    [引用 user="Peter Borenstein"]我很惊讶没有更直接的答案...

    我不是。 这些工具不是 TI 的主要产品、半导体供应商在这方面没有特别出色的业绩。

    Robert

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    尊敬的 Peter:

    询问并回答、Uniflash 使用脚本、Uniflash 从文件中读取地址、通过 XDS 编程器对 USER_REG0/USER_REG1进行编程、然后增量以引入下一个地址。

    关于脚本的写入方式、访问文件的方式等的详细信息。 嗯、这是由 TI 的第三方处理的、所以您的猜测和我的猜测一样好。 很抱歉。 :(

    您可能可以浏览和/或询问 UniFlash 人员客户通常是如何为其编写/运行脚本的、但我无法想象、已经有十几次被问及这样的主题。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    感谢您的内部消息。 知道兔子孔底部有一个解决方案是很好的。

    我有几个帖子/问题、但许多评论线充斥着其他问题和困惑。

    如果我仍然需要帮助、我将如何联系 Uniflash 团队?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    尊敬的 Peter:

    就我所知、Code Composer 论坛也会处理所有 Uniflash 问题 :e2e.ti.com/.../81
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Peter、Ralph、

    关于 MAC 地址的编程、我认为这需要更多的定制软件来从远程位置获取值、并将其写入产品的 MCU、可能在测试阶段。 具有 MAC 地址的产品似乎不太可能没有某种串行通信端口、这将是该号码传输的方便途径... 这种自动化似乎不仅仅是"编程(Uniflash)解决方案中的脚本"、因为它将需要某种反馈到公司中分配的池的任何位置... 如何避免意外重新分配 Mac 地址、对吧?

    现在,关于独特的身份,我必须表达我的那种快感! 使用 Tivas 已经有这么多年了、从 LM 和 XM 器件型号开始、我还不知道这类寄存器。 作为他们的"Register 182..."、我是否可以相信我在阅读数据表摘要时的注意力之前已经消失了一些行? 有趣的是、我不仅在很久以前发布了一个与如何唯一标识产品相关的问题、而且在其他帖子中、我还建议我们在产品中应用的 EEPROM 的器件型号以获得128位 UID、从未出现过这样的评论! 哇哦。

    Ralph、UNOQUEID0-3的128位内容是否确实是整个 TM4C 系列的唯一 ID? 这种独特性是否延伸到您了解的其他 TI 器件?

    此致

    布鲁诺

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好 Bruno、

    UNIQUEID0-3的内容仅针对 TM4C129x 器件、而不是 TM4C123x 器件。 这也可能说明您没有早点发现它们的存在、希望这会让您感觉更不那么受蔑视! )

    128位在所有 TM4C129x 器件中都是唯一的、但与任何其他 TI 系列器件相比、它没有任何独特之处。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Ralph、

    感谢您的回复! 提及123x 系列没有 ID 功能也是一个相关的问题。

    这种"唯一 id"主题可能是开发者之间反复讨论的话题、也可能是没有明确解决方案的话题... 例如、Mac 地址具有用于分配池的调节板、应该存在(可能存在、我从未搜索到这么深)一个真正的硬件"全球唯一 id"。。 我想说、128位仍然足以"构建任何活动的处理设备"-但即使如此、在这些摩尔时代、这种说法也是有风险的。

    为了共享状态、在我们的情况下、我们将继续使用带有128位 UID 的外部小型低成本 EEPROM IC。 它是"我们选择的方式"、可以唯一地识别我们的产品。 但是、至少在了解了129x 功能后、如果小型库有一些枯燥的时间、跟踪该功能也不会有任何伤害、或者建议同事使用 IC 开发其他产品。

    谢谢

    布鲁诺

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    存在 UUID: en.wikipedia.org/.../Universally_unique_identifier

    "虽然 UUID 复制的概率不是零、但它足够接近零、可以忽略不计"
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    谢谢 Peter、我没有意识到这一点。 此声明

    [引用 user="Peter Borenstein"]"虽然 UUID 复制的概率不是零、但它足够接近零、可以忽略不计"[/quot]

    仅适用于其中一种情况(随机生成情况、其他情况依赖于先前存在的独特值)、似乎有点乐观。

    他们认为可以忽略的是、如果(这些条件不是很小的考虑因素)

    • 您可以假定独立的随机数生成
    • 您可以假设随机数生成实际上是随机的**

    那么,在1018代产品中,您有50%的重复可能性***。 这是很多数字、但也是很高的可能性。 它实际上可以在您到达该点时保证碰撞。 事实上,我认为你想把人口限制在一个范围内,这样碰撞的概率就小于106的1个部分,也许更少。 这将大幅减少可用数字的数量、尽管我不确定数量。 可能是一个数量级还是两个数量级? 还有其他问题吗? 如果有人想解决这个问题、这是一个可以解决的问题。

    作为可能需要多少个数字的代理、请考虑 CPU 市场、据 Wiki https://en.wikipedia.org/wiki/Microprocessor#Market_statistics 称 、该市场最近的年增长率为1010、并且在不断增长。 因此,根据碰撞的可能性,您愿意接受此技术的局限性,以便用作“保证的唯一”产品标识符*。

    好消息是、唯一唯一的唯一要求是通信、这会使我们返回到 MAC 编号。 由于它依赖于赋值而不是随机数、因此小数大小仍然可以保证唯一性。 我看到了一些建议、这些建议甚至会以同样的方式删除 IP 地址的要求。 但不确定如何在"路由器"后面管理它。

    我认为 Bruno 的方法是唯一一种能够跨多个供应商的产品使用唯一标识符的方法(如果您可以保证您的所有产品都有 MAC、那么这是一种替代方法)、我认为我已经看到过几家供应商提供类似产品。 问题是、您需要所有产品使用同一供应商提供的同一 IC。 请记住、我没有看到任何人真正需要公司内所有产品的唯一序列号、仅在产品或产品系列中。 这可以显著减少问题。

    好消息是、您可以使用此方法将序列号应用到您的产品中、只有在您在相当长的时间内开始接近当前的 CPU 生产时、这才会成为一个问题。 OTOH 您可以从公司池中分配序列号(或使用上述 IC)、并以更简单的方式解决问题。

    Robert

    *在18-10年的数量级上、以最近的生产率计算、108年的寿命和8-2年的降低概率再次降至106年。 这仍然是一个很大的数字、但全球产量的增加或对更强的防撞能力的愿望将进一步降低这一数字。 随机数生成器中的任何缺陷也是如此。 一个对您有利的项目是、大多数项目的寿命相当短、因此它们的标识符可以返回到可用池。

    **根据定义,在某种程度上,任何 PRNG 都将是非随机的。

    ***这是1036的空间中的一个,因此在碰撞可能性较高之前,您不会填充太多的空间。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    R.A. "唯一保证唯一性的方法是非随机的。"

    而反过来说(也许),“只是“随机性”的保证——结果是“独特”吗?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我不认为是这样、随机性内没有要求唯一性。

    据我所知、我对其他信息持开放态度、唯一的真正随机数生成器使用物理随机过程。 也就是说、伪随机数生成器(PRNG)足以满足大多数用途。 但它们确实有局限性,这些局限性的影响导致了 PRNG 的改进。 我听说的主要改进驱动因素是加密(这种通用唯一 ID 似乎是其表弟)和仿真。

    Robert
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我一直在想了解嵌入在 Stellaris 串行引导加载程序应用中的 BootP 随机种子发生器。 代码被写入时就好像它可以将一个 MAC 地址从瘦空气分配给空白 USER0/1寄存器一样。  它似乎没有将随机 MAC 分配给已擦除的 M3 MCU、或者在刷写引导加载程序后执行任何有用的操作。

    随机种子数生成器的目的是什么、或许一次在专用网络的范围内认为是可以的、但 RFC 没有对其进行如此严格的监管、就像晚期的互联网一样。 然而 、当引导加载程序通过 JTAG 闪存并忘记 LM 闪存 M4易于更新 USER0/1寄存器时、代码似乎无法在已擦除的 M3上注册 USER0/1寄存器。

    //
    //
    //! 计算新的随机数。
    //!
    //! 此函数使用线性
    //!计算新的假随机数 一致随机数生成器。 请注意、如果
    //! 未使用生成的随机数、应使用 N 位上限
    //! 而不是较低的 N 位、因为它们更具随机性(例如、使用
    //! ``RandomNumber()>> 28''而不是``RandomNumber()& 15')。
    //!
    //! 返回32位伪随机数。
    ////
    *****************
    静态无符号长
    RandomNumber (void)
    {
    //
    //生成一个具有线性随机一致性的新假随机数
    //数字生成器。 这个新的随机数成为下一个的种子
    //随机数。
    //
    G_ulRandomSeed =(g_ulRandomSeed * 1664525)+ 1013904223;
    
    //
    //返回新的随机数。
    //
    return (g_ulRandomSeed);
    }
    
    
    //
    //如果未使用静态 MAC 地址,则从获取 MAC 地址
    //闪存用户寄存器。
    //
    #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
    
    //
    //从 MAC 地址播种随机数生成器。
    //
    G_ulRandomSeed =*(无符号长整型*)(g_sMACAddr.addr + 2);
    
    //
    //初始化 UIP 堆栈。
    //
    uip_init();
    uip_arp_init ();
    
    //
    //对 MAC 地址进行编程。
    //
    HWREG (ETH_base + MAC_O_IA0)=*((unsigned long *) g_sMACAddr.addr);
    HWREG (ETH_base + MAC_O_IA1)=*(无符号短整型*)(g_sMACAddr.addr + 4);
    uip_setethaddr (g_sMACAddr);