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.

[参考译文] MSPM0L1105:MSPM0 系列 IC 编程问题

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1608743/mspm0l1105-mspm0-series-ic-programming-issue

器件型号: MSPM0L1105

尊敬的 TI 团队:

在测试的编程期间 NONMAIN 较大的栅极区域 MSPM0L1105TRGER ,我发现,当检查在擦除操作后 NONMAIN 区域是否为空时,该设备的 NONMAIN 区域没有完全擦除。

如果无法可靠地确认擦除状态、这可能会导致之后写入数据时出现问题。

 

此外、我还在上测试编程 MSPM0C1106SRGER

编程后、我无法读回正确的编程数据。

根据我的调查、编程之前的残留数据似乎仍可能保留在 IC 中。  

只能在复位 IC 后读取正确的数据;但是、某些客户的编程文件在 IC 复位后无法通信。

我还观察到、当读取同一地址两次时、第二次读取将返回正确的数据。  

 

您能否建议如何解决 MSPM0L1105TRGER NONMAIN 区域未完成擦除的问题?

或者、这种行为是否也与读取擦除操作之前存在的残留内部数据有关?

对于 MSPM0C1106SRGER 上读取预编程残留数据的问题、是否可以通过读取两次来解决该问题、或者是否有更合适的解决方案?

谢谢你。

Steve。

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

    您好 Steve、

    最近、在测试的编程时 NONMAIN 较大的栅极区域 MSPM0L1105TRGER ,我发现,当检查在擦除操作后 NONMAIN 区域是否为空时,该设备的 NONMAIN 区域没有完全擦除。[/报价]

    您能否分享如何在 prorgam 之前对 NONMAIN 进行编程并回读 NONMAIN?

    B.R.

    Sal

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

    尊敬的 Sal:

    我还没有达到 NONMAIN 区域编程的步骤。

    目前、我只执行擦除操作、并在擦除后检查该区域是否为空白。

    我正在使用的擦除和读取过程基于文档的第 6 章、链接如下:

    https://www.ti.com/lit/ug/slau847e/slau847e.pdf。

    谢谢。

    Steve。

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

    您好 Steve、

    因此、您正在使用 flashctl 来擦除 NONMAIN 并在应用程序代码中读回?

    如果是、我可以使用 EVM 板进行一些测试、

    B.R.

    Sal

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

    尊敬的 Sal:

    很抱歉之前没有说明。 我们是 Dediprog、是第三方编程工具供应商。

    我目前正在按照您的 TRM 中描述的过程擦除和读取 NONMAIN 区域、并将此流程集成到我们的编程工具中。

    谢谢。

    Steve。

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

    您好 Steve、

    我发现、在执行擦除操作后检查 NONMAIN 区域是否为空白时、此器件的 NONMAIN 区域未完全擦除。

    您是否可以尝试回读闪存值来查看它是否全部为 0xFF?  

    我还观察到、当读取同一地址两次时、第二次读取会返回正确的数据。  [/报价]

    是否在执行新的 flashctl 操作之前重置 STATCMD? 有时 CMD 状态会在稍后预期更新、因此您可能会读回命令传递(这是之前的操作状态)、但实际上新命令正在执行。

    我目前正在按照您的 TRM 中描述的程序来擦除和读取 NONMAIN 区域、并将此流程集成到我们的编程工具中。

    还有另一个有用的文档可供您开发编程器工具时参考: https://www.ti.com/lit/an/slaaeo5/slaaeo5.pdf 

    B.R.

    Sal

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

    尊敬的 Sal:

    您能否尝试读回闪存值来查看它是否全部为 0xFF?  [/报价]

    当我尝试读回数据时、我发现它不是完全为 0xFF。

    您是否在新的 flashctl 操作之前重置 STATCMD? 有时 CMD 状态会在稍后预期更新、因此您可以读回命令传递(这是之前的操作状态)、但实际上新命令正在执行。

    我在 TRM 中看到了这种描述、这是否意味着可以通过在每次闪存操作之前向 CMDTYPE 寄存器写入 0x00000005h 来解决所述的问题?

    还有另一个有用的文档可供您开发编程器工具: https://www.ti.com/lit/an/slaaeo5/slaaeo5.pdf 

    明白了、谢谢! 我将在我这边再次回顾一下。
     
     
     谢谢。 Steve。

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

    您好 Steve、

    当我尝试读回数据时、我发现它不是完全 0xFF。

    原来是这样。 如果您等待一段时间、那么读回值如何?  

    由于我在 TRM 中看到了这一说明、这是否意味着可以通过在每次闪存操作之前向 CMDTYPE 寄存器写入 0x00000005h 来解决所述的问题?

    这不是一回事。 可通过以下寄存器禁用高速缓存:

    如果有此帮助、您可以尝试。

    您是否在新的 flashctl 操作之前重置了 STATCMD? 有时 CMD 状态会在稍后预期更新、因此您可以读回命令传递(这是之前的操作状态)、但实际上新命令正在执行。

    当 CPU 时钟高于 32MHz 时会发现此问题、也许这也会对您的实现产生影响。

    了解了、谢谢! 我将再次查看。

    我不是编程器/调试器工具的专家。 如果您在这个问题上需要进一步的帮助、请告诉我。 我将与内部团队专家交谈、看看是否有其他建议。

    B.R.

    Sal