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.

[参考译文] TMS320F28069:CMS 解锁不起作用。

Guru**** 2582405 points
Other Parts Discussed in Thread: TMS320F28069

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

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/881349/tms320f28069-unlocking-cms-does-not-work

器件型号:TMS320F28069

主题:TMS320F28069:无法解锁 CMS。

 

大家好、团队、

我尝试进入安全模式、然后从它返回到不安全模式。 进入 S.M.工作正常、但是
返回 U.M 失败、尽管使用了建议的过程。
因此,调试器和引导加载程序都无法刷写器件--它似乎丢失了。

我采取的步骤是:

 我映射了一个将密码传送到 ADR 的常数数组 UINT16 CsmPwl[8]。 3f7ff8:
  

声明:
#pragma DATA_SECTION (CsmPwl、"CsmPwlFile");

const 结构 csm_PWL CsmPwl ={0x434C、0x4F53、0x4544、0x2034、0x2052、 0x4F4D、0x414E、0x5321};

使用映射文件和调试器、我验证了密码数组的位置是否正确、以及元素的顺序是否正确。

我验证了所有的 KEY 寄存器在程序启动时都是0xFFFF。
已验证关键变量 CsmRegs 是否已映射至正确的地址。

在调试器启动时(在调用执行取消保护的函数之前)、器件不安全
尽管上述密码已编程到闪存中。

函数 DeviceUnsecure()的调用会在 main()开始的声明后立即执行。 (下一页列表)。

--我刚刚单步执行声明,在调用 DeviceUnsecure 之前停止
此时、我手动将 CSMSCR 设置为0x8000。
从调试器的显示屏可以看到、该器件立即切换至安全模式。

然后我停止调试并在没有调试器的情况下重新启动器件(断电/打开)。
我希望器件现在不安全、因为 DeviceUnsecure 被称为程序流中的第一个操作。 请参阅下面的代码列表。

我发现尽管进行了该调用、器件仍然安全、因此现在无法进行上述访问。

那么、可能发生或发生了什么情况? 手册中是否有错误?

 

 

 

 

 

void main( void )


   uint16 u16_main_scratch = 0;
   易失性 eEEP_RET eepState;
   int iwait;

   DeviceUnsecure ();

   f32_gl_id_sollwert = 0.0;
   ledStation.all =关;
   (笑声)
   (笑声)

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

DeviceUnsecure 列表():

(笑声)

#define PASSWORD_LENGTH 8.

(笑声)

void DeviceUnsecure (void)


  uint16 i;
  uint16 *pCell;
  volatile uint16 tmp;

  pCell =(UINT16*)&CsmPwl;    // CsmPWL 是全局变量!

  对于(i = 0;i < password_length;i++) tmp =*pCell++;

  EALLOW;
  CsmRegs.KEY0 = 0x434C;
  CsmRegs.key1 = 0x4F53;
  CsmRegs.key2 = 0x4544;
  CsmRegs.key3 = 0x2034;
  CsmRegs.KEY4=0x2052;
  CsmRegs.KEY5=0x4F4D;
  CsmRegs.KEY6 = 0x414E;
  CsmRegs.KEY7=0x5321;
  EDIS;

 

全局 CsmPwl 的声明/初始化:

const 结构 csm_PWL CsmPwl ={0x434C、0x4F53、0x4544、0x2034、0x2052、 0x4F4D、0x414E、0x5321};

 

此致、

Goetz

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

    下面是我对该问题的理解:

    • 您使用密码保护设备。
    • 您已验证密码是否已写入正确的位置。
    • 循环通电后、您现在无法使用 CCS 连接到器件。

    上述内容是否正确?  

    如果是、这是因为 ECSL 跳闸了调试器连接。 请使用等待引导模式、与器件建立连接、然后取消保护器件。 之前在 e2e 论坛上已经多次讨论过这一点。 请使用"site:e2e.ti.com wait and boot"进行 Google 搜索、以获取有用的链接

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

    您好!

    问题略有不同:

    您的前2项陈述正确。

    • 我使用调试器将程序加载到器件中(在 main()的开头停止)。
    • 我检查了是否一切都正常、是否有密码存储等 是的。
    • 然后、我手动将 CSMSCR 中的 FORCESEC 位设置为1。 可以看到、处理器立即做出反应
      调试器中。
    • 我没有继续执行代码、但此时终止了调试器。
    • 然后、我在没有调试器的情况下重新启动了器件。
    •  DeviceUnsecure ()是程序执行的第一个操作(在初始化1个变量之后)。
      因此,处理器应在程序启动时自行解锁(请查看 main()和中的代码片段
      DeviceUnsecure ()在我昨天的帖子中)。
    • 但处理器未解锁。 显然,即使在执行 DeviceUnsecure ()之后,它仍然受到保护
    • 因此、调试器无法再访问它、并且无法再次刷写(无论是否由调试器或进行刷写)
      引导加载程序)。

    所以、我在问自己、这里有什么问题。 至于我、我无法判断是否涉及 ECSL。。

    顺便说一下:在这种情况下、什么实际上意味着"跳闸"? 此术语经常使用、但在文档中从未解释过。
                          我只知道"旅行"是"旅行"和朋友的同义词... ;-)

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

    您好、再说一次、

    这是对我以前给我的答复的补充----以避免误解。

    • 我们的器件配置为直接分支(通过0x3F7FF6)到我们自开发的引导加载程序
      进而直接分支到应用程序代码... 我的回复中提到了该引导加载程序。
    • 我们从未使用仿真进行调试(因此我完全不熟悉 ECSL 主题)。

    此致、

    Goetz

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

    [引用]然后我手动将 CSMSCR 中的 FORCESEC 位设置为1。 在调试器中可以看到、处理器立即做出反应。 [/报价]

    通过"反应"、我假设您是指 ECSL 踢进并跳过 JTAG 连接、CCS 窗口中的错误消息就证明了这一点。 无论如何、此时您的器件由密码保护。

    [引用]我没有继续执行代码、但此时终止了调试器。 [/报价]

    您是指您断开了连接?

    [引用]然后、我在没有调试器的情况下重新启动了器件。 [/报价]

    这是否意味着您无需 JTAG 电缆或 JTAG 电缆但不调用 CCS 即可重新启动?

    DeviceUnsecure ()是程序执行的第一个操作(在初始化1个变量之后)。 因此,处理器应在程序启动时自行解锁(请查看昨天发布的 main()和 DeviceUnsecure ()中的代码片段)。 [/报价]

    当处理器执行不安全功能时、是否连接了 JTAG 连接器?

    [报价]但处理器未解锁。 显然,即使在执行 DeviceUnsecure ()之后,它仍然受到保护。 [/报价]

    假设你在 Unsecure 函数之后有一个无限循环。 如果在执行不安全操作后尝试通过 CCS 连接到器件、会发生什么情况?

    因此、调试器无法再访问它、并且无法再次刷写(无论调试器还是引导加载程序都是如此)。 [/报价]

    如前所述、如果默认访问闪存等安全区域、ECSL 将不允许在安全器件上连接调试器。 这就是我们在引导 ROM 中使用等待模式的原因。 您需要将引导模式更改为等待、建立 CCS 连接并*然后*擦除闪存。

    [引述]所以、我在问自己、这里有什么问题。 至于我、我无法判断是否涉及 ECSL。。 [/报价]

    ECSL 将涉及配置为引导至闪存的安全器件(在您的设置中就是这种情况)

    [引述]顺便说一下:在这种情况下、什么实际上是"旅行"? 此术语经常使用、但在文档中从未解释过。 [/报价]

    "TRIP"意味着调试探针和器件之间的连接将断开、因此 CCS 将无法再与器件通信。 类似于断路器跳闸的东西。 即断开连接。

    [引用]我们从未使用仿真进行调试(因此我完全不熟悉 ECSL 主题)。 [/报价]

    很抱歉我不明白。 "仿真"一词用词不当、因为没有任何内容是"模拟"。 我们将所有 TI 文档中的"仿真器"一词替换为"调试探针"。 使用 CCS 进行调试、对吧?

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

    通过"反应"、我假设您是指 ECSL 踢进并跳过 JTAG 连接、CCS 窗口中的错误消息就证明了这一点。 无论如何、此时您的器件由密码保护。

    =>"反应"意味着、例如、"Expressions"-和"Variable"窗口中显示的所有变量都变为零。 ===无法再读取它们。

    您是指您断开了连接?

    =>我终止了调试器、然后断开了探针。

    然后、我在没有调试器的情况下重新启动了器件。

    这是否意味着您无需 JTAG 电缆或 JTAG 电缆但不调用 CCS 即可重新启动?

    =>可以。

    当处理器执行不安全功能时、是否连接了 JTAG 连接器?

    =>否、器件"按原样"启动。

    假设你在 Unsecure 函数之后有一个无限循环。 如果在执行不安全操作后尝试通过 CCS 连接到器件、会发生什么情况?

    =>在 Unsecure()调用之后循环不会立即发生。 但是、在调用后执行一些"线性"代码(例如初始化)后、会到达主循环、可以从某些 CAN 输出中看到该循环。 在此状态下、我重新连接了调试探针并启动了 CCS 调试器。

    如前所述、如果默认访问闪存等安全区域、ECSL 将不允许在安全器件上连接调试器。 这就是我们在引导 ROM 中使用等待模式的原因。 您需要将引导模式更改为等待、建立 CCS 连接并*然后*擦除闪存。

    =>我这么做了。 通过外部电路、GPIO37保持高电平、同时 GPIO34被拉低。 OTP 未使用。 如果我理解正确的话、这个配置应该使调试器能够访问目标。 实际上、它不是。 调试器报告错误1135、然后在消息框关闭后终止。

    "TRIP"意味着调试探针和器件之间的连接将断开、因此 CCS 将无法再与器件通信。 类似于断路器跳闸的东西。 即断开连接。

    =>还可以 ;-)

    很抱歉我不明白。 "仿真"一词用词不当、因为没有任何内容是"模拟"。 我们将所有 TI 文档中的"仿真器"一词替换为"调试探针"。 使用 CCS 进行调试、对吧?

    =>确定、已复制。 ;-)

     

    注释:作为一个实验、我在尝试启动调试器之前更改了属性/调试/闪存设置对话框中的配置:
    我更改了代码安全密钥 条目、以便它们反映硬编码的密码。 然后、我再次尝试在目标器件处于"等待"状态时启动调试器。

    令人惊讶的是、调试器成功地清除了配置为被清除的闪存扇区、然后开始向闪存写入代码。 但这在不确定状态下停止、并显示"非零"错误消息。 在以后的尝试中,无法再现这种行为。 因此、我将密钥条目重新配置回0xFFFF。

    因此、当前状态为:

    -硬编码密码的固件(在闪存扇区 H、G 和 F 上)已被擦除。 由于调试器被配置为只擦除扇区 H 至 C、我认为密码仍然存在。
    -我们的引导加载程序(扇区 A 保留)仍在板上。
    -即使处于"等待"状态、调试器也无法访问目标。

     

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

    我(已更新)对您当前情况的理解:

    您有一个安全器件、您可以在未连接 JTAG 连接器的情况下加电。 此器件上电、执行不安全功能和一些初始化、并在循环中结束。 此时、器件处于不安全状态。 但是、当您连接 JTAG 连接器、调用 CCS 并尝试连接到器件时、您无法这样做、并且 CCS 返回错误。 我想知道您的不安全功能是否会出现一些错误。  

    您将器件置于等待引导模式并为其加电。 现在、当您连接 JTAG 连接器、调用 CCS 并尝试连接到器件时、您无法这样做、并且 CCS 返回错误。 这很奇怪。 即使器件是安全的、等待引导模式也应允许您连接到 CCS。 这是该模式的目的。

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

    我(已更新)对您当前情况的理解:

    您有一个安全器件、您可以在未连接 JTAG 连接器的情况下加电。 此器件上电、执行不安全功能和一些初始化、并在循环中结束。 此时、器件应处于不安全状态。 但是、当您连接 JTAG 连接器、调用 CCS 并尝试连接到器件时、您无法这样做、并且 CCS 返回错误。

    =>可以。 完全正确。

    我想知道您的不安全功能是否会出现一些错误。  

    =>这是我的软件中使用的不安全功能。 此外,我引述所涉声明:

    -------------------- 函数:-------------------------------------------------------

    void DeviceUnsecure (void)

       uint16 i;
       uint16 *pCell;
       volatile uint16 tmp;

       pCell =(UINT16*)&CsmPwl;  //我在非锁定 SW 版本中检查了 CsmPwl 的地址:正确:0x3F7FF8

       对于(i = 0;i < password_length;i++) tmp =*pCell++;

       EALLOW;
       CsmRegs.KEY0 = 0x434C;   // CsmRegs 的地址:也正确:0xAE0
       CsmRegs.key1 = 0x4F53;
       CsmRegs.key2 = 0x4544;
       CsmRegs.key3 = 0x2034;
       CsmRegs.KEY4=0x2052;
       CsmRegs.KEY5=0x4F4D;
       CsmRegs.KEY6 = 0x414E;
       CsmRegs.KEY7=0x5321;
       EDIS;


    ---------------- 声明 ------

    密码声明:

    const 结构 csm_PWL CsmPwl ={0x434C、0x4F53、0x4544、0x2034、0x2052、 0x4F4D、0x414E、0x5321};

    密钥寄存器的结构声明:

    struct csm_regs{
      UINT16          KEY0;   //密钥寄存器位15-0
      uint16          key1;   //密钥寄存器位31-16
      uint16          key2;   //密钥寄存器位47-32
      uint16          key3;   //密钥寄存器位63-48
      uint16          KEY4;   //键寄存器位79-64
      uint16          KEY5;   //键寄存器位95-80
      uint16          KEY6;   //密钥寄存器位111-96
      uint16          KEY7;   //密钥寄存器位127-112
      uint16          rsvd1;  //保留
      uint16          rsvd2;  //保留
      uint16          rsvd3;  //保留
      uint16          rsvd4;  //保留
      uint16          rsvd5;  //保留
      uint16          rsvd6;  //保留
      uint16          rsvd7;  //保留
      UNION CSMSCR_REG CSMSCR; // CSM 状态和控制寄存器
    };

    密码结构的声明:

    struct csm_PWL{
      UINT16  PSWD0; // PSWD 位15-0
      UINT16  PSWD1; // PSWD 位31-16
      UINT16  PSWD2; // PSWD 位47-32
      UINT16  PSWD3; // PSWD 位63-48
      uint16  PSWD4; // PSWD 位79-64
      UINT16  PSWD5; // PSWD 位95-80
      UINT16  PSWD6; // PSWD 位111-96
      UINT16  PSWD7; // PSWD 位127-112
    };

    您将器件置于等待引导模式并为其加电。 现在、当您连接 JTAG 连接器、调用 CCS 并尝试连接到器件时、您无法这样做、并且 CCS 返回错误。

    =>是的、这也是正确的。 我重新检查了的状态
    (GPIO37 - GPIO34 -/TRST) 通过测量:=>(HI - LOW - HI)。 OTP 被配置为未使用。

    使用 hexfile,我检查了区域0x3F7F80的正确填充。 0x3F7FF7 => 0x0000
                                                            0x3F7FF8 0x3F7FFF => 0xFFFF
                                                            0x000AE0 0x000AE7 => 0x0000

    这很奇怪。 即使器件是安全的、等待引导模式也应允许您连接到 CCS。 这是该模式的目的。

    =>嗯... 最后我可以尝试使用(可能也会牺牲)另一个板。 我会告诉你
    您的结果...

    到目前为止、谢谢。。

    BR Goetz

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

     

    抱歉:我刚发送的帖子的更正:


    ========================================================================
    /TRST  未测量 HI低!!!
    ========================================================================


    BR Goetz

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

     

    再次抱歉:我 的第二个帖子更正了#2:


    ========================================================================
    在有问题的电路板上,区域0x3F7FF8…… 0x3F7FFF 被载入密码、字的顺序正确。

    这是通过 hexfile 检查的。
    ========================================================================


    BR Goetz

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

    您可以像这样"简化"您的密码吗?

    1111

    FFFF

    FFFF

    FFFF

    FFFF

    FFFF

    FFFF

    1111

    这只是为了使其"对称"、因此您执行操作的顺序无关紧要。  

    [报价]/TRST 未测量 HI 但低!!![/报价]

    -TRST 应该为低电平才能正常运行。 即、未连接 JTAG 连接器(且 CCS 控制器件)  

    [报价]在相关的主板上,区域0x3F7FF8…… 0x3F7FFF 被载入密码、字的顺序正确。 这是通过 hexfile 检查的。 [/报价]

    好的。 您是否也验证了闪存中的地址?

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

    Ubstadt 您好

    -TRST 应该为低电平才能正常运行。 即、未连接 JTAG 连接器(且 CCS 控制器件)  

    在有问题的电路板上,区域0x3F7FF8…… 0x3F7FFF 被载入密码、字的顺序正确。 这是通过 hexfile 检查的。

    好的。 您是否也验证了闪存中的地址?

    =>这只能通过读取 hexfile 来完成(我们使用它并行生成)
    因为一旦器件被锁定、调试器将无法访问。 因此、我无法进行检查
    地址。

    --

    至于 hexfile 生成:
    我想知道的是、生成了一个包含的附加 hexfile (*。M10)
    带密码的行:

    (插入空白以提高可读性):

    S00600004844521B
    S3 15 003F7FF8 434C 4F53 4544 2034 2052 4F4D 414E 5321 15.
    S705003D80003D

    而在"常规"六文件中、此行是

    S3 15 003F7FF8 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 44.

    但是、无论如何、由于调试器使用*。out 文件来刷写器件、上述内容应该没有意义。

    顺便说一下:是否可以将包含密码的行集成到"常规"十六进制文件中、以便这样做
    当需要使用 hexfile 加载时、只能加载一个 hexfile?

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

    毕竟、我们决定不使用密码(至少初始)、因为每一个都使用密码
    尝试失败、我们丢失了整个电路板...

    BR Goetz

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

    在闪存中对代码进行编程后、您应该能够在不断开调试器的情况下检查密码位置的内容。  

    不过,我觉得奇怪的是,您无法在等待模式下连接。 您可以尝试 SCI 模式吗?  

    这是您自己的电路板还是 LaunchPad/controlCARD 之类的 TI 电路板?

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

    在闪存中对代码进行编程后、您应该能够在不断开调试器的情况下检查密码位置的内容。  

    坦率地说、我们犹豫要再试一次:每次失败的尝试都会导致电路板丢失...
    因此、我们尝试从"等待模式"端解决问题。 此外、这具有这种优势
    它排除了作为故障原因的不正当软件...

    不过,我觉得奇怪的是,您无法在等待模式下连接。 您可以尝试 SCI 模式吗?  

    我们所做的是拉取 GPIO37:高电平、GPIO34:低电平;/TRST:低电平、只要 JTAG 未连接即可。
    我们通过直接测量引脚来验证了这一点:一切都正确。 随后、我们连接了 JTAG 和
    已尝试启动 CCS 调试器。 CCS 报告错误1135:无法连接。

    =>我们还需要考虑什么??? 是否有已知的副作用可能会因其他引脚的状态而发生?

    这是您自己的电路板还是 LaunchPad/controlCARD 之类的 TI 电路板?

    不是、它是专有电路板。

     

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

    您好!

    [引述]

    我们所做的是拉取 GPIO37:高电平、GPIO34:低电平;/TRST:低电平、只要 JTAG 未连接即可。
    我们通过直接测量引脚来验证了这一点:一切都正确。 随后、我们连接了 JTAG 和
    已尝试启动 CCS 调试器。 CCS 报告错误1135:无法连接。

    =>我们还需要考虑什么??? 是否有已知的副作用可能会因其他引脚的状态而发生? [/报价]

    这应将器件置于"等待"模式。 您能否尝试通过目标配置文件运行"测试连接"。 双击目标配置文件、然后单击"Test Connection"。 这是为了检查电路板上的 JTAG 信号是否没有问题。

    此致、

    Vivek Singh