[参考译文] TMS320F28388S：使用 CCS 12.8.1 进行多核调试

尊敬的 Ed：
请预计响应会延迟。
此致、
Lakshya

尊敬的 Lakshya：

               自从停止使用 10.4.2 以来、我们的 GEL 文件没有更改。  系统不允许我上传 ccxml 文件、因此我将这两个文件压缩在一起。  GEL 文件是我们在 CM 内核上使用的文件、删除存储器初始化以保护我们。  但症状不会随着移除而改变。  我还附上了我尝试连接的工程的 ccxml。  如您所见、GEL 脚本中没有任何内容。  也许这就是问题所在？

另一个数据点： 如果我仅将 CM 内核工程附加到正在运行的系统、我可以看到 CM 的 GEL 文件正在执行、并且 CM 内核在 TI 引导加载程序中的 0x00001816 附近运行。  当我连接到 C1 和 CM 内核时、我没有看到 CM 的 GEL 文件正在执行、并且 CM 内核卡在 0x00000000。

谢谢您、

教育

e2e.ti.com/.../5488.Files.zip

尊敬的 Ed：
如您所述、您正在为 CM 内核使用这个几乎为空的 GEL 脚本。
是否对内核 1 工程使用默认的 GEL 脚本？

我将尝试使用一些 C2000 SDK 多核示例进行复制、然后会回复您。

尊敬的 Ed：

是否对两个内核都使用闪存配置？

是的、我们是！

顺便说一句,我可能不能回复几个星期,所以不要期望任何快。  一旦我回来,我将能够回应。

谢谢您、

教育

尊敬的 Ed：

我使用的是 F28338D 和 CCS 20.3.1。  

我正在使用  SDK 中的工程 led_ex1_c28x_cm_blinky_cm 和 C：\Users\a1251238\projects\e2e\multiple_f2838\led_ex1_c28x_cm_blinky_cpu1。

在目标配置中、我将为 CPU1 和 CM 内核使用您共享的空 GEL 脚本。

未选中中的‘Halt the target on a connect'选项

我连接良好、如果您遇到此问题、能否尝试对上述示例进行测试？  

我成功连接到 Core 1、但与 CM 内核的连接导致该内核被重置并卡在地址 0。

在这里您讨论的是 CM 内核还是 CPU1？

注意 — 我们已停止对 CCS 版本 10.4.2  的支持。

此致、

Lakshya

尊敬的 Lakshva：

               我们使用的是 F28388S（我不知道 F28338D 是否存在拼写错误）和 CCS 12.8.1。  我们使用 CCS 10.4.2 已有多年、对我们来说非常有用。  但由于停止对该版本的支持,我们改为 12.8.1,现在我们试图使它以与 10.4.2 相同的方式工作。  我们经常使用的功能之一是能够连接到正在运行的系统而不会干扰它。

谢谢您、

教育

尊敬的 Lakshya：

               如果您愿意、我可以在私人对话中回答第一个问题。

               当我们第一次开始这个项目时、在硬件到达之前、我使用了 388 评估板、该板使用了 388D。  我能够调试两个内核、而不会出现任何问题。  我不记得我是否低调地连接、但我认为我可能有、因为我更喜欢以这种方式进行调试。  因此、从 CCS 的角度来看、388D 和 388S 可能存在差异。

               但我们认为我们已经找到了该问题的解决方法。  如果我们删除 Target Configs 中的 GEL 文件、并删除 Debug Configuration 中的工程、则会在不干扰系统的情况下连接工程。  然后、我们可以手动连接并加载相应的符号。

               在 Target Configuration 中、当我们删除通常使用的 GEL 文件时、最终会将其替换为“..\targetConfigs"。“。  这只是指代工程的 targetConfigs 文件夹吗？  它没有 GEL 脚本、因此大概连接过程没有执行任何操作？

谢谢您、  

教育

尊敬的 Ed：  
目前我只有 388D、我使用 CCS20.3.1 进行了检查、工作正常。
从调试的角度来看、CCS 与 388D 和 388S 的性质不应存在 AMU 差异。
我将使用 388D 测试 12.8.1、如果它不像您所描述的 388S 那样正常工作、那么我们可以得出结论：388D 和 388S 之间可能没有任何差异、并且可能存在 12.8.1 版本中的一些错误。
我会让您知道更新信息。
此致、
Lakshya   

感谢您发送编修。

此致、

教育

尊敬的 Ed：  
我使用了 CCS 12.8.1 并执行了相同的实验来检查在调试会话期间连接到 CM 内核时 CPU1 内核的复位。
它没有重置 CPU1 内核。
我正在使用您共享的 GEL 脚本 、用于目标配置中的 CPU1 和 CM 内核。
我在 388D 上进行了这个实验。
 

我使用了 C2000 SDK 中的多核闪烁示例、其中涉及 CPU1 和 CM 内核。

为了检查 CPU1 内核是否复位、我执行了以下操作：

在 CPU1 示例中、我在 LED 闪烁循环之前添加了一个空的 while 循环。 因此、除非在调试会话期间显式更改循环条件、否则相应的 LED 不会闪烁。

当这两个工程都刷写时、只有与 CM 内核工程对应的 LED 会闪烁。 CPU1 内核 LED 不闪烁、因为它卡在空循环中。

启动无工程调试会话并连接到 CPU1 内核后、我加载符号并更改了循环条件、以便程序进入 LED 在循环期间闪烁。 执行此操作后、两个 LED 开始闪烁。

接下来、当连接到 CM 内核并加载符号时、我仍然观察到两个 LED 闪烁。 这表示 CPU1 未复位。

388D 和 388S 器件之间在这方面的行为不应有任何差异。 但是、我仍将在内部进行检查、以确认是否存在任何特定于器件的差异而导致该行为。

如果您可以共享一个示例工程、在其中观察 CPU1 内核在连接到 CM 内核时得到复位、也会很有帮助。

您是否尝试过新版本的 CCS、是否也会在其中看到相同的问题？

尊敬的 Lakshya：

很抱歉、您的回复太慢。  直到现在我才能进入网站。

我们试过 CCS 测试、但最终决定使用 CCS 12.8.1、因此我没有该版本的任何数据供您使用。

抱歉、

教育

尊敬的 Ed：
通过数据,我指的是任何多核的例子,这可以展示这种现象的重置,因为我尝试复制这在 theia 以及 12.8.1 .
模式。 我的 Core 未重置。 该示例工程与 CCS 版本无关。

GEL 文件是我们在 CM 内核上使用的文件、删除了存储器初始化以保护我们。  [/报价]

我假设您在 CCS 目录之外有一个自定义 GEL 文件、该文件一直用作起始 GEL 文件。 此 GEL 仅定义 startup () 以设置存储器映射、那是吗？ 您的 GEL 是否包含任何其他 GEL 文件？

在“Target Configuration“中、当我们删除通常使用的 GEL 文件时、最终会将其替换为“..\targetConfigs"。“。  这只是指代工程的 targetConfigs 文件夹吗？  [/报价]

当没有 GEL 文件时、它是默认占位符。 这毫无意义、我想我们在 CCS 20 中将其清理干净。  

请注意、ccxml 文件中 GEL 文件的相对路径根目录是 CCS 安装目录中的某个位置。 我认为是这样  \ccs\ccs_base\common\targetdb。 也可能是“DebugServer"内“内的某个文件夹。 我不确定具体是哪一个、但它不是工程文件夹的根目录。

好的。  谢谢你 Ki。

教育

正确。  现在、根据设计、它不包含任何内容、因此不会干扰任何内容。