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.

[参考译文] TMS320F2800156-Q1:使用操作"保持已停止&quot 设置断点时出现问题;位于0x8058

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

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1482229/tms320f2800156-q1-trouble-setting-breakpoint-with-the-action-remain-halted-at-0x8058

器件型号:TMS320F2800156-Q1
Thread 中讨论的其他器件:UNIFLASH

工具/软件:

您好的团队、  

我向我的客户提出这个问题。  

如果他们使用 CCS12.7.1和 XDS110将.out 文件编程到芯片、则一切都正常。

但是、如果他们使用 uniflash 和 XDS110将十六进制文件(在默认配置中由 C2000 hex 生成)编程到芯片、则会有一定的概率会出现在警告下方:

如果他们再次使用 uniflash 程序和十六进制文件、则会显示下面的错误:

现在、如果他们再次使用 CCS 对文件进行编程、它将显示在 error 下方、我们无法对闪存进行任何输出文件编程。

e2e.ti.com/.../ccs1.jfif

客户已经有4块电路板有同样的 现象。  无论它是再次上电还是断电或者执行其他操作、闪存都无法重新编程

我看到了类似的主题: TMS320F28384D:在删除断点时采取"保持停止"操作时遇到问题- C2000微控制器论坛- C2000Tm︎ 微控制器- TI E2E 支持论坛、它说这可能是由 XRSn 电路引起的、因此我检查了 XRSn 电路、HV_XRSn 将与 XRSn 引脚连接并进行调试。 2引脚 JTAG 设计与4引脚 JTAG 不一样,我和标准2引脚 JTAG 电路相比,似乎还可以。

所以、  

1.这种现象的可能原因是什么,我们如何找出问题?

2.您能帮助检查此电路是否正常吗?

3.我想尝试 TMS320F28384D 中提到的相同测试:移除断点时出现"保持停止"- C2000微控制器论坛- C2000Tm︎ 微控制器- TI E2E 支持论坛、我将基于 flashapi_ex1_programming 工程修改演示、需要更改 cmd 文件、我想检查我们是否有任何演示在 RAM 中运行但要擦除、对闪存进行编程? 或者、  在修改 flashapi_ex1_programming 工程时、您有任何建议吗?

BRS

Shuqing

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

    尊敬的 Shuqing:

    Unknown 说:
    2. 您能帮助检查 XRSn 电路是否正常吗?

    您能否在 XRSn 引脚中进行检查以确定其行为是否正确? 如果是由于 XRSn 设计或电路板制造缺陷导致的、您还可以通过在 controlCARD 上测试同一程序来确认情况。

    Unknown 说:
    m 根据 flashapi_ex1_programming 工程修改演示、需要更改 cmd 文件、我想检查我们是否有任何演示在 ram 中运行、但要擦除、编程闪存? 或者、  在修改 flashapi_ex1_programming 工程时、您有任何建议吗?

    SCI/CAN 闪存内核示例可能满足该要求、因为它们在 RAM 中执行并擦除/编程闪存。

    此致、

    马特

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

    尊敬的 Matt:

    感谢您的建议、我检查了他们的闪存数据、所有数据都是0、我检查了客户 Z1_CR/Z2_CR 寄存器、值为0x80000、这意味着该芯片将被永久锁定。 但客户确认他们在开发过程中未使用 DCSM、我向他们检查了工程、因为他们的 CMD 中没有 dcsm.asm 和相关内容。

    并且他们告知在使用 CCS 对.out 文件进行编程时不会出现错误。 当他们使用 Uniflash 对十六进制进行编程时、它们可能满足此要求、并且并不是在每个电路板中都会发生这种情况、因此我认为他们的工程可能不会修改 OTP。 我认为这可能是他们 Unilfash 的不当操作。

    在 TRM 中、我们可以看到、芯片永久阻塞可能是由以下原因导致的:

    1.

    2.

    现在他们可以成功连接调试器、但无法编程、我不确定上述情况是否会与客户产生相同的现象。

    所以、

    1. 您能帮助回答什么原因可能导致芯片永久阻塞、但可以连接调试器吗?
    2.  Uniflash 中有关此情况的相关操作是什么?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Shuqing:

    我将继续就该问题咨询多位专家、但无法与 F2800157器件进行复制。

    如何生成十六进制文件?

    此致、

    马特

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

    尊敬的 Matt:

    它们使用 CCS12.7.1、下面的显示了 hex2000配置:

    e2e.ti.com/.../ccs.jfif

    WHA 更,你能告诉我什么会导致芯片 永久阻塞 ,但调试器可以连接除了我上面提到的? 在 uniflash 中需要执行什么操作?

    BRS

    Shuqing

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

    尊敬的 Shuqing:

    JTAG 仍然可以访问不安全的资源、这就是 UniFlash 能够连接的原因。 您需要提供密码(CSMKEY)来解锁受保护的 DCSM 区域(除非 CSMPSWD 为 ALL_0)。 您能否验证 CSMPSWD 的内容是否全部为0?

    如果器件意外永久锁定、例如在闪存编程期间断电、则无法将其禁用。 如果十六进制文件存在问题(某个文件映射到密码位置)、则需要更正链接器 cmd 文件(使用 type = DSECT)、以便不会将任何内容编程到密码位置。 有关更多详细信息、请参阅以下指南: https://software-dl.ti.com/ccs/esd/documents/sdto_cgt_linker_special_section_types.html

    此致、

    马特

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

    尊敬的 Matt:

    CSMPSWD 并非全部为0、但我们无法使用它来解锁芯片。 我们使用片上工具。

    e2e.ti.com/.../3302.webwxgetmsgimg.jfif

    如果器件意外永久锁定、例如闪存编程期间断电、则无法将其禁用

    您的意思是、当闪存编程期间发生断电时、即使客户不对 OTP 进行编程、它也可能会锁定芯片?

    什么其他原因可能会 永久锁定芯片?

    我 将十六进制文件(客户程序在芯片上)编程到 EVM、这样不会锁定我的芯片、因此我不认为十六进制文件会锁定芯片。

    BRS

    Shuqing

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

    您好、Shuqing、

    所附的屏幕截图仅显示 Z1_CSMKEY (解锁器件时必须输入的密码)、而不是 Z1_CSMPSWD。 但是、Z1_CR 的值支持 CSM 密码全为零并且器件被永久锁定、如您在前面提到的。

    有关器件锁定和解锁的更多详细信息、请参阅 https://www.ti.com/video/6336139910112

    您的意思是、当闪存编程期间发生断电时、即使客户不对 OTP 进行编程、它也可能锁定芯片?

    是的、这是可以实现的。

    您能否共享工程的链接器命令文件和映射文件?

    此致、

    马特

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

    尊敬的 Matt:

    这是十六进制文件:  

    e2e.ti.com/.../hex.txt

    BRS

    Shuqing

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

    您好:

    Unknown 说:
    如果他们使用 CCS12.7.1和 XDS110将.out 文件编程到芯片中、则一切正常。

    如果您使用 UniFlash 对同一.out 文件进行编程、这也可以吗? 还是遇到同样的问题?

    您是否还能提供*。out 文件?

    谢谢

    Ki

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

    尊敬的 Ki:

    这并不是每次都发生的。 因此、我不确定是否使用 uniflash 来对输出文件进行编程、是否会导致程序。

    我想知道当我们使用 uniflash 时、什么操作会锁定芯片? 我可以首先使用此检查列表与客户进行检查  

    BRS

    Shuqing

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

    尊敬的 Matt 和 Ki:  

    我还上传他们的 cmd 文件:e2e.ti.com/.../7077.MEMORY.txt

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    我想知道当我们使用 uniflash 时、什么操作会锁定芯片?

    Matt -您能回答这个问题吗?

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

    尊敬的 Matt:

    添加更多信息:我检查存储器、所有 OTP 和闪存数据均为零;Z1DCSM 寄存器如下面的所示:

    e2e.ti.com/.../DCSM1.jfif

    我不知道 LINKPOINTER 为何变为0xFFFFC000、是因为芯片被 永久锁定?

    有一件事很奇怪:即使芯片被锁定, CPU 访问也不会被锁定,这意味着我们可以运行应用(尽管应用可能会耗尽)。 但我发现客户的应用程序不运行到闪存中、我连接调试并加载 BootROM 的符号、它会显示代码卡在以下位置(0x3fb709~3fb711):

    BRS

    Shuqing

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

    尊敬的 Shuqing:

    为了让您保持更新-我们已经向 UniFlash 团队提出了这个问题以了解可能导致十六进制程序加载锁定器件的原因。

    有一件事很奇怪:即使芯片被锁定、CPU 访问也不会被锁定、这意味着我们可以运行应用程序(尽管该应用程序可能会耗尽)。 但我发现客户的应用程序不运行到闪存中、我连接调试并加载 BootROM 的符号、它显示代码卡在以下位置(0x3fb709~3fb711):

    这是不寻常的。 我将联系此器件的引导 ROM 专家、看看闪存被锁定时是否符合预期。

    我想知道当我们使用 uniflash 时、什么操作会锁定芯片? 我可以使用此检查清单首先与客户进行检查 

    我还会在收到器件后立即尝试在我这边重现此问题、但您可以尝试在 UniFlash 中再次复制它并监控 XRSn 信号吗? 如果是、请发送 XRSn 的示波器屏幕截图、指示何时发生。

    此致、

    马特

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

    尊敬的 Matt:

    我必须进行更新、再次提示案例、 并且客户使用 CCS 进行编程、可以看到 CCS 配置: tidrive.ext.ti.com/.../3bc24111-9c1d-4e9e-be92-bbd5c1f5d3ef

    更重要的是、代码也滞留在 0x3fb709~3fb711中、即使是通过我要求他们进行编程、他们也不会监视 XRSn。

    BRS

    Shuqing

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

    尊敬的 Shuqing:

    请允许我花一些时间了解 CCS 配置。 同时、请建议客户在编程期间监控 XRSn 线路、并截屏失败时发生的情况。

    下星期一、我将与同事讨论导致设备卡在引导 ROM 中的原因。 我还订购了部件以复制问题、并在收到后尝试复制、但这可能需要数周的时间。

    此致、

    马特

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

    尊敬的 Matt:

    我将让客户监视 XRSn、希望您 今天能回答代码滞留在 BootROM 中的原因、谢谢。

    BRS

    Shuqing

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

    尊敬的 Shuqing:

    我仍在等待同事反馈有关引导 ROM 的信息、但我有 UniFlash 团队的意见:

    "在第一个屏幕截图中、"二进制"复选框处于打开状态。 对于十六进制加载、该复选框默认处于关闭状态。 也许用户手动开启二进制加载、然后将其转换为二进制加载而不是十六进制加载。 未指定地址字段、因此我认为 UniFlash 尝试加载到地址0x0、并写入无法访问的存储器位置、因此他们在控制台中收到该初始错误。 不过、我认为该文件不足以写入安全字段存储器位置、因此我不知道此后器件会被锁定的原因。

    无论如何、建议确保其在 UniFlash 中关闭该二进制复选框。"

    我还会注意到、由于通过 CCS 加载程序会锁定器件出现相同的错误、因此 CCS/UniFlash 加载器件的方式一定不会出现问题。 客户能否共享其项目的.map 文件?

    此致、
    马特

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

    尊敬的 Shuqing:

    要让您随时更新已完成的操作:

    1. 我已收到所有器件、并尝试使用您提供的十六进制文件重现客户的问题。 我已经能够成功将程序刷写到器件上、甚至在编程期间执行 XRSn、但无法重现问题。
    2. 我一直在与引导 ROM 专家讨论这个问题、他正在与闪存团队验证有关客户看到的1T/2T 就绪信号问题的信息。

    此致、

    马特

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

    您对此问题有任何更新吗? 是否确定了一项决议?

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

    由于几周内未收到回复、我假设问题已解决并结束该主题。