[参考译文] UniFlash：[错误] C28xx_CPU2：为闪存操作设置 GSxMSEL 寄存器时出错

您好，

[引用 userid="479799" url="~/support/tools/code-composer-studio 组/CCCS /f/code-composer-studio 论坛/1071258/uniflash 错误-c28xx_CPU2-error-setting-the -sxmsel register-for-flash-operations"[MSXxx_CPU2]针对闪存操作设置错误：[MS28xx_CPU2]：2022年21月01日 ：针对闪存操作的报价单：[MSxx_CPU2]：针对闪存操作

我过去见过这个问题。 这通常是由于您仅连接到 CPU2并尝试刷新时导致的：

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/718227/launchxl-f28379d-unable-to-download-cpu2-flash

解决方法是先连接到 CPU1，然后再连接 CPU2。

当前版本的工具(CCS 和 UniFlash)应具有此功能，以便在首次连接到 CPU2时，该工具将先自动连接 CPU1，然后再完成连接到 CPU2。  

由于您使用的是 UniFlash 7 (当前版本)，我不知道为什么会出现此问题。 我无法重现该问题。

当您刷新设备时，是否在同一会话中先刷新 CPU1，然后刷新 CPU2？ 或者您只是在会话中尝试刷新 CPU2？ 如果是后者，您是否可以尝试先刷新 CPU1 (并确保 CPU1保持连接)，然后立即刷新 CPU2并查看其是否正常工作？

谢谢

Ki

感谢您的回复。

我正在会话中刷新两个 CPU，如下所示：

-加载会话文件。

-单击加载映像 CPU1

-选择 Program CPU2 (程序 CPU2)选项卡

-单击加载图像 CPU2

右上角的设置如下所示，这似乎符合您的建议。

但是，如果我取消选择“保持连接”...

问题消失了，这是不直观的，所以我不知道为什么这种方法奏效。 可以告诉我吗？

遗憾的是，此设置似乎不在会话文件中，因此我无法为最终用户控制它。

另一个奇怪的地方是，屏幕截图中 CPU 旁边的点总是灰色的。 我认为连接时这些绿色光亮，这是正确的吗？

你好，Kier，

您的 CPU1应用程序是否配置 GSxLOCK 寄存器？

谢谢，此致，
瓦姆西

Vamsi 您好，

谢谢，但我的申请对这些注册没有任何影响。

UniFlash 出现问题。 选中“保持连接”复选框时，我收到错误消息。 如果未选中，则不会出现错误。 问题是为什么应该这样做。

吉尔。

你好，Kier，

感谢您提供信息。

我们将在内部进行讨论并与您沟通。

现在，请继续使用适合您的配置。

谢谢，此致，
瓦姆西

吉尔

您能否启用 DS 日志记录并重现问题？ 然后压缩日志并将其附加到此线程。

有关 DS 日志记录的更多详细信息，请参阅：

https://software-dl.ti.com/ccs/esd/uniflash/docs/v7_0/uniflash_quick_start_guide.html#defect-reporting-and-logging

此外，是否可以共享两个 CPU 上闪存的文件？

谢谢

Ki

[引用 userid="479799" url="~/support/tools/code-composer-studio 组/CCCS /f/code-composer-studio 论坛/1071258/uniflash -error-c28xx_CPU2-error-setting-the -sgsxmse-register-for-flash-operations /3965353屏幕截图，这些图片总是位于 CPU 的另一个灰色区域。] 我认为连接时这些绿色光亮，这是正确的吗？

是的，它应该这样做。 已为此提交了一个错误。 跟踪链接： https://sir.ext.ti.com/jira/browse/EXT_EP-10734

谢谢

Ki

e2e.ti.com/.../2630.ds.zip

谢谢 Ki。 日志已上传。

回到 Vamsi 的问题，实际上我的应用程序确实为 CPU2提供了对某些 GSRAM 块的主控，但它不会锁定任何配置。 但是，我本以为调试器仿真器在连接 CPU 时会重置 CPU，这样 MSEL regsiters 就会返回到默认值。 我想我会提到它以防它有所帮助。

吉尔。

吉尔

只要您的应用程序没有锁定，插件就应该能够向 GSxMSEL 写入数据。  我们的团队正在尝试重现此问题-截至目前，他们能够成功地进行计划。   

感谢您的记录- Ki 的团队将进行审核并回复您。

谢谢，此致，
瓦姆西

Kier -只是一个快速更新，我们仍在调查此问题。 我们将在收到更新时通知您。

谢谢

Ki

吉尔

只是为了实验：在 CPU1应用程序代码中，您可以尝试写入0x7C0，而不是在 GSxMSEL 中写入0x67C0，看看这是否消除了错误？  这有助于我们确认我们的观察结果并继续修复。  谢谢你。

此致，
瓦姆西

Vamsi 您好，

那么您的意思是不要让 CPU2控制 GS13和 GS14？ 如果是这样，我尝试了，但没有改进。

但是，如果我删除了以下所有行，那么问题就会消失。  请记住，我必须修改 CPU2应用程序的其他部分，使其不再尝试写入这些区域以阻止其掉落。

    /* Give permanent control of these blocks to CPU2. */
    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS6,  MEMCFG_GSRAMMASTER_CPU2 );
    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS7,  MEMCFG_GSRAMMASTER_CPU2 );
    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS8,  MEMCFG_GSRAMMASTER_CPU2 );
    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS9,  MEMCFG_GSRAMMASTER_CPU2 );
    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS10, MEMCFG_GSRAMMASTER_CPU2 );

    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS13, MEMCFG_GSRAMMASTER_CPU2 );
    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS14, MEMCFG_GSRAMMASTER_CPU2 );

这有帮助吗？

吉尔

感谢您的参与。  这有助于我们进一步分析。  我们会再回来的。

此致，
瓦姆西