[参考译文] J721EXSOMXEVM：CCS 12.6 -通过 EVM 板载 XDS110调试探针使用无引导模式连接 SoC 内核时出现 JTAG 故障

您好、George、

您的 EVM 是 J721E EVM 还是 J721S2 EVM？

两个 SoC 非常不同、您不能期望具有 J721E.GEL 文件用于 J721S2。 要使用的目标配置文件也不同(不同之处在于连接到 M3内核时 GEL 自动加载)。

  有关 J721S2的详细步骤、请参阅"RTOS SDK 的 J721S2 CCS 设置"部分。  

此致

苏曼

Suman、

我对这种困惑感到抱歉。

我有一个 J721E EVM。

在最初的发布过程中、我 SOM 从提供的列表中输入/挑选了唯一一个错误的 EVM/EVM、并且在该发布的标题、正文和标签中错误地重复了该错误。

请帮助我根据以下 SOM 目标 EVM/EVM 更改/更正我的原始标题/帖子中错误引用的 EVM/EVM SOM ...

盒装 EVM 标签...

EVM 通用板……

TDA4x 和 DRA8x

J21EXCP01EVM

EVM 模块上系统

TDA4VMx 和 DRA829Vx

J21EXSOMG01EVM

因此、J721E.GEL 是在目标配置创建过程中使用的正确工具。

请告知如何纠正与 SOM 内核的"无引导模式"连接。

谢谢。

-乔治

您好、George、

我编辑了标题。

您的机器上是否安装了任何其他 CCS？

此致

苏曼

Suman、

Windows 7 64位 SP1系统上最初安装的 CCS 是 CCS 12.5、且最近更新为 CCS 12.6。

CCS 12.6更新安装在已安装 CCS 12.5的基础上、位于 C：\TI\ccs1250路径中。  我希望 CCS 12.6更新安装在单独的 C：\TI\ccs1260路径中。  因此、我无法再以旧的快捷方式运行 CCS 12.5、eclipse\ccstudio.exe 将导致启动 CCS 12.6。

J721E.GEL 文件上的时间戳是2022年12月1日1：53 PM、比2024年1月发布的日期 CCS 12.6旧得多。  我认为这个 GEL 脚本在 CCS 12.5安装程序中是相同的。

话虽如此、如果我的存储器工作正常、与处于"无引导模式"的 EVM/CC26_0的连接问题已预先存在 SOM 12.6更新。

我想重申的是、在使用"SD 引导模式"引导 EVM 之后、我可以通过 JTAG/目标配置连接到 EVM 的 SOC C71X_0 CPU。

这意味着在"SD 引导模式"期间运行的软件已正确设置 EVM 和 SOM 硬件、允许连接到 C71X_0 CPU、而 J721E.GEL 脚本在从 DMSC_Cortex_M3_0运行时并非如此。

此外、我想报告的是、通过 EVM 的板载 XDS110调试探针将 Project_C7x.out 文件加载到 C71X_0的时间非常慢。  我的。 输出文件的大小相当大、只有~23MB (并非所有都能加载到内存中)、并且在开始下载~4小时后、下载的可加载部分不到10%。

显然、它花费这么长的时间、有些东西是与之不符的。

我会让这个慢下载继续在一个晚上,看看它得到了多远的早晨。  在这个速度,我不是太希望,它将永远完成。

我将使用 BH-USB-560v2 System Trace 仿真器通过 EVM 上的 JTAG/MIPI 连接创建类似的目标配置。

我希望 BH-USB-560v2 JTAG 下载将得到大幅改进。

通过 JTAG 下载的速度必须得到解决并且明显更快、否则此平台无法用于测试目的。

谢谢。

-乔治

Suman、

感谢您将我的原始发布更改为正确的 EVM 和 SOM。

我想指出的是、我在这篇文章中输入的"标签"未更改、未使用正确的 SOM、即  J21EXSOMG01EVM。

我不知道在这一点上是否可以改变,但如果可以的话,这将是伟大的,避免与其他人在搜索和错误地访问这篇文章前进的困惑。

谢谢。

-乔治

您好、George、

在 Scripting Console 中运行 launch.js 脚本是否有任何问题？ 您是否得到了一个显示"Happy Debugging！！"的日志？

请注意、 SDK 9.1版本已进行正式测试、且 CCS 版本12.4支持。

此致、

内哈尔

您好、George、

guiquan wu said:

我想指出我为此帖子输入的"标签"没有更改以使用我正确的 SOM，即 J21EXSOMG01EVM

TI.com 上的通用可搜索器件型号为 J721EXSOMXEVM。 我已经调整了标题和标签来使用它。 X 是通配符、G 是通用 SoM 器件型号。

此致

苏曼

您好、George、

guiquan wu said:

CCS 12.6更新安装在 C：\TI\ccs1250路径中现有 soc 12.5安装的顶部。  我希望 CCS 12.6更新安装在单独的 C：\TI\ccs1260路径中。  因此、我无法再运行 CCS 12.5、因为旧的快捷方式和 eclipse\ccstudio.exe 会启动 CCS 12.6。

CCS 安装设计为并行安装、如果您尚未专门选择相应文件夹、听起来在安装脚本中有一个错误(可能错过了对 ccs1260的更改)。

无论如何、我建议执行卸载、并执行全新安装(或选择其他路径)。

此致

苏曼

Neehar,

我尚未从脚本控制台运行 lauch.js 脚本、因此无法报告其执行情况。

我在 Windows 7 64位 SP1上使用 CCS 12.6。

正如我在原帖中所述、我已创建目标配置"J721E_EVM_XDS110_ccxml.ccxml" Debug_Probe。  

我按照"第6节"中的说明、针对此 EVM 将目标配置设置为板载 XDS110调试探针。 J721E 的 CCS 设置"

https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/09_01_00_06/exports/docs/psdk_rtos/docs/user_guide/overview.html

我提及 SDK 9.1仅用于执行 J721E EVM 目标的仿真设置和配置。  这是我找到此文档的唯一位置。  否则、我不使用 SDK 9.1、而是在创建满足 SYS/BIOS 需求的工程时使用 SDK 7.3。

已将 J721E  EVM 配置为"无引导模式"。

当我启动该 Target Configuration (右键点击启动配置)时、它会进入 Fruition、在 Debug 透视图的"Debug"选项卡中提供一个包含所有 CPU 的 Target Configuration、即 CortexA72_0_0、CortexA72_0_1、C71X_0、 等、处于"断开"状态。

然后、我右键点击 DMSC_Cortex_M3_0 CPU、它会开始执行在该 CPU 设置期间预配置的 J721E.GEL。

这会生成在我的原始帖子中记录的控制台输出。

单步执行脚本需要一段时间、并且似乎挂起、无法完成以下步骤...

DMSC_Cortex_M3_0：GEL 输出：对主 PLL 0 (主 PLL)编程

检查 C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E.gel 时显示正在执行同一相对路径中的一组其他 GEL。

以下是包含 J721E.GEL 的文件夹的内容

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_R5LOCKStep.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_DDR32SS\J7_DDR_config.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_DDR32SS\J7-DDR-addr-map-offers.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_DDR32SS\J7-DDR-EVM-LP4-2133_v0.9.1.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_DDR32SS\J7-DDR-EVM-LP4-3733.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_DDR32SS\J7-DDR-EVM-LP4-3733_v0.9.1.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_DDR32SS\J7-DDR-EVM-LP4-4266_v0.9.1.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_OBSCLK\J721E_OBSCLK.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_PADCONFIG\J721E_PADCONFIG.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_PLL\J721E_PLL_MMR.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_PLL\J721E_PLL_OFC1.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_PLL\J721E_PLL_PARAMS_OFC1.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_PSC\J721E_PSC.gel

我想、相对路径"J721E_DDR32SS"中的一组 GEL 是在执行 J721E.GEL 期间"挂起"时发生的情况。

我似乎很清楚、这些"仿真" gel 是在 CCS 安装过程中提供的、并不涉及构建项目时使用的 SDK。

是的、我使用的是 CCS 12.6而非 CCS 12.4、且这些 GEL 值可能已从12.4变为12.6伏、但我认为这些改变会带来改进、但不是能够带来颠覆性变革。

我将请 TI 确认、CCS 12.6中提供的 GEL 可用于 J721E_DRA829_TDA4VM。

由于 GEL 不是作为 SDK 的一部分提供、而是作为 CCS 安装提供、因此在工程编译期间使用什么 SDK 应该无关紧要。

GEL 仅作为 CCS 的一部分、用于执行必要的硬件设置、允许连接到各种器件和 CPU。  这些 GEL 不会在运行时使用、也不会作为用于构建工程的 SDK 的一部分。

因此、我不关心您的评论"请注意、 SDK 9.1版本已进行正式测试、且支持 CCS 版本12.4。"、因为我不使用 SDK 9.1、也不使用 CCS 12.4。

我构建的工程已在 CCS 12.6上完成、并使用 SDK 7.3、具体是因为这是最后一个在 C71x 器件上支持 SYS/BIOS 的 TI SDK。

我希望此新增信息有助于推动此 J721E"无引导模式"问题向前发展、解决 J712E.GEL 在连接到  DMSC_Cortex_M3_0时无法完成的原因、因为在尝试连接到所需的目标 CPU C71X_0之前、此操作需要成功。

我期待 TI 在这方面的解决。

谢谢。

-乔治

Suman、

我在运行 CCS 12.5期间检测到 CCS 12.6更新、因此我让该更新继续进行。

在此更新过程中、我在任何时候都未要求提供安装位置、最终 CCS 12.6安装在 ccs1250路径中。

我同意、这是更新安装程序中的错误。

有时我会卸载 CCS、并分别重新安装 CCS 12.5和 CCS 12.6。

我不认为在 CCS 12.5之上安装此 CCS 12.6更新是导致我看到"无引导模式"连接问题的原因。

谢谢。

-乔治

您好、George、

guiquan wu said:

当我启动该 Target Configuration (右键点击启动配置)时、它会进入 Fruition、在 Debug 透视图的"Debug"选项卡中提供一个包含所有 CPU 的 Target Configuration、即 CortexA72_0_0、CortexA72_0_1、C71X_0、 等、处于"断开"状态。

然后、我右键点击 DMSC_Cortex_M3_0 CPU、它会开始执行在该 CPU 设置期间预配置的 J721E.GEL。

这会生成在我的原始帖子中记录的控制台输出。

[/报价]

启动目标配置后、可以正常看到所有 CPU 处于"断开连接"状态。  然后、您是否可以尝试 按照说明中所示、 而不是右键点击 M3内核来加载 launch.js 脚本。 您应该会看到与原始帖子类似的控制台日志。

guiquan wu said:

是的，我使用的是 soc 12.6与 CCS 12.4，这些凝胶可能已从12.4变为12.6，但我认为这些改变将是有益的，不会妨碍改进。

是的、我同意、GEL 脚本应该在 CCS 12.6上仍然有效。

感谢您提供了所有澄清信息。

谢谢。

内哈尔

[/quote]

Neehar,

我已经在我的机器上执行了 CCS 卸载。

如你所知、我最初执行了 CCS 12.5安装、一段时间后、更新程序找到并将 CCS 12.6安装在 C：\TI\ccs1250路径顶部。

目前我已经在路径 C：\TI\ccs1250中安装了 CCS 12.5。

已根据指令创建目标配置...

第2步：设置 CCS 目标配置和 gels 文件

我想您仍然想将以下 GEL 附加到 DMSC_Cortex_M3_0的初始化脚本

 ..\..\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E.gel

如果没有、请告知、因为无论是否使用 launch.js、或者右键点击"connect to the CPU"、此脚本均已运行。

我修改了 launch.js 的 pdkPath 以指向我的安装的正确的以下路径...

C：\ti\ti-processor-sdk-rtos-j721e-evm-09_01_00_06\pdk_jacinto_09_01_00_22\packages/ti\drv\sciclient\tools\ccsLoadDmsc\j721e

注意： 我提到9.1的唯一目的是在脚本控制台中使用"launch.js"、但我不在 Project_C7中使用它。  这对于 EVM 连接和 GEL 初始化应该不会构成问题。

将 EVM 设置为"无引导模式"、并使用 Debug_Probe 根据说明配置的板载 J721E_XDS110_ccxml.ccxml。

已通电 EVM。

右键单击启动的目标配置... J721E_XDS_ccxml.ccxml Debug_Probe。

打开 Scripting Console。

执行了 launch.js、如下所示：得到以下输出...

JS：>loadJSFile ("C：\TI\ti-processor-sdk-rtos-j721e-evm-09_01_00_06\pdk_jacinto_09_01_00_22\packages/ti\drv\sciclient\tools\ccsLoadDmsc\j721e\launch.js")
正在连接到 DMSC_Cortex_M3_0！
连接到目标时出错：200000ms 后超时(C：\TI\ti-processor-sdk-rtos-j721e-evm-09_01_00_06\pdk_jacinto_09_01_00_22\packages/ti\drv\sciclient\tools\ccsLoadDmsc\j721e\launch.js#110)

在目标配置控制台输出上看到以下输出后、会发生脚本控制台错误输出。

许多 GEL 弹出对话框出现、最后一个对话框说...

GEL 表达式：OnTargetConnect()

"J721E_EVM_XDS110_ccxml.ccxml" Debug_Probe 的控制台窗口显示了以下内容...

DMSC_Cortex_M3_0：GEL 输出：为 R5F 配置 ATCM
DMSC_Cortex_M3_0：GEL 输出：已配置 ATCM。
DMSC_Cortex_M3_0：GEL 输出：当前仅支持由 DMSC 内部的 Cortex-M3使用此 GEL。
DMSC_Cortex_M3_0：GEL 输出：不要从 SoC 上的任何其他 CPU 运行此 GEL。
DMSC_Cortex_M3_0：GEL 输出：此脚本将第一个地址转换区域设置为[0x8000_0000、0x0000_0000]。
DMSC_Cortex_M3_0：GEL 输出：它还将第二个地址转换区域设置为[0x6000_0000、0x4000_0000]。
DMSC_Cortex_M3_0：GEL 输出：这与 SoC DV 假设一致。
DMSC_Cortex_M3_0：GEL 输出：C66xx_0配置为复位模式下的等待
DMSC_Cortex_M3_0：GEL 输出：C66xx_1配置为复位模式下的等待
DMSC_Cortex_M3_0：GEL 输出：C71x_0配置为复位模式下的等待
DMSC_Cortex_M3_0：GEL 输出：R5F 停止位被置位。
DMSC_Cortex_M3_0：GEL 输出：为 LPSC_WKUPMCU2MAIN 上电
DMSC_Cortex_M3_0：GEL 输出：无需更改。
DMSC_Cortex_M3_0：GEL 输出：检查 LPSC_WKUPMCU2MAIN
DMSC_Cortex_M3_0：GEL 输出：电源域：开启
DMSC_Cortex_M3_0：GEL 输出：模块状态：启用
DMSC_Cortex_M3_0：GEL 输出：对所有 PLL 进行编程。
DMSC_Cortex_M3_0：GEL 输出：对主 PLL 0 (主 PLL)编程

当未执行 launch.js 时、此输出似乎与之前相同、即在 DMS_Cortex_M3_0上右键点击"CONNECT"。

我等待了相当长的时间(~1小时),它没有继续超过这个步骤,弹出的对话框 OnTargetConnect()剩余。

我希望您可以建议快速解决该问题。

我的目标是成功连接到 C71X_0、然后加载/调试我的构建项目。

此 EVM 初始化/连接故障正在成为一个非常大的问题、阻碍我继续进行评估。

谢谢。

-乔治

您好、George、

guiquan wu said:

我想您仍然想将以下 GEL 附加到 DMSC_Cortex_M3_0的初始化脚本

 ..\..\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E.gel

如果没有、请告知、因为无论是否使用 launch.js、或者右键点击"connect to the CPU"、此脚本均已运行。

[/报价]

是的、您仍需要将 GEL 文件附加到 M3初始化脚本。

guiquan wu said:

我修改了 launch.js 的 pdkPath 以指向我的安装的正确的以下路径...

[/报价]

您是否可以尝试将其修改为仅作为 PDK 的路径？ 在您的情况下、它可能是：

pdkPath ="C：\TI\ti-processor-sdk-rtos-j721e-evm-09_01_00_06\pdk_jacinto_09_01_00_22\packages\"；

谢谢！

内哈尔

[/quote]

Neehar,

感谢您在将..\..\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E.gel 附加到 DMSC_Cortex_M3_0时提供的确认。

我按照您的建议进一步修改了 pdkPath。

结果与之前完全相同。

情况似乎发展得非常缓慢、即每个控制台输出行进度之间间隔~10秒以上。

Scripting Console 中运行 launch.js 产生的错误表明在执行脚本执行后  200000ms (200秒)。

这不会修复运行缓慢的问题、但我是否应该将 launch.js 中的超时值增加到更大的值、例如400000ms？

谢谢。

-乔治

Neehar,

增加超时时间对这个问题没有影响。

超时错误已延迟、但仍然发生。

-乔治

Neehar,

EVM 上是否有其他开关设置可能未针对"无引导模式"正确配置？

我只按照设置说明轻触了 SW8和 SW9。

我未改动 EVM 上的任何其他开关的 发货方式。

"SD Boot Mode"(SD 引导模式)工作正常。

对于采用"SD 引导模式"的串行通信、我确实注意到插入 EVM 图位置连接器1的 USB 串行电缆非常敏感。  提供的任一电缆都具有相同的敏感连接。  如果在 EVM 连接器1号位置触碰该电缆、则会断开与 PC 的连接。

我知道这一点与 EVM 连接器位置6处的板载 XDS110 USB 调试探针连接没有关系、但我也想分享这个问题。

谢谢。

-乔治

Neehar,

我在目标配置中运行了"Test Connection"选项、该选项为 Debug_Probe 的板载 XDS110调试探针创建了"J721E_EVM_XDS110_XDS110_XDS110.ccxml"。

这是输出、您可以看到没有报告任何错误...

[开始：德州仪器 XDS110 USB Debug Probe_0]

执行命令：

%CCS_base%/common/uscif/dbgjtag -f %boarddatfilename%-RV -o -S 完整性

[结果]

-------- [打印主板配置路径名}-->--------------------

C：\Users\GenUser\AppData\Local\TEXASI~1\
ccs\ccs1250\0\0\BrdBat\testBoard.dat

-------- [打印复位命令软件日志文件]----------

此实用程序已选择100/110/510类产品。
该实用程序将加载适配器'jioxds110.dll'。
库构建日期为"STEP 6 2023"。
库构建时间为"09：57：39"。
库软件包版本为"9.13.0.00201"。
库组件版本为'35.35.35.5.0'。
控制器不使用可编程 FPGA。
控制器的版本号为"5"(0x00000005)。
控制器的插入长度为"0"(0x00000000)。
此实用程序将尝试重置控制器。
此实用程序已成功重置控制器。

-------- [打印重设命令硬件日志文件]----------

通过切换 JTAG TRST 信号可重置扫描路径。
控制器是具有 USB 接口的 XDS110。
从控制器到目标的链路是直接的(无电缆)。
该软件针对 XDS110功能进行了配置。
控制器无法监控 EMU[0]引脚上的值。
控制器无法监测 EMU[1]引脚上的值。
控制器无法控制输出引脚上的时序。
控制器无法控制输入引脚上的时序。
扫描路径链路延迟已精确设置为"0"(0x0000)。

-------- [在 JTAG IR 上执行完整性扫描测试}-->--------

此测试将使用64个32位字的块。
此测试将只应用一次。

使用0xFFFFFFFF 执行测试。
扫描测试：1、跳过：0、失败：0
使用0x00000000进行测试。
扫描测试：2、跳过：0、失败：0
使用0xFE03E0E2进行测试。
扫描测试：3、跳过：0、失败：0
使用0x01FC1F1D 进行测试。
扫描测试：4、跳过：0、失败：0
使用0x5533CCAA 进行测试。
扫描测试：5、跳过：0、失败：0
使用0xAACC3355进行测试。
扫描测试：6、跳过：0、失败：0
所有值均已正确扫描。

JTAG IR 完整性扫描测试已成功。

-------- [在 JTAG DR 上执行完整性扫描测试-------------------------------------------------------

此测试将使用64个32位字的块。
此测试将只应用一次。

使用0xFFFFFFFF 执行测试。
扫描测试：1、跳过：0、失败：0
使用0x00000000进行测试。
扫描测试：2、跳过：0、失败：0
使用0xFE03E0E2进行测试。
扫描测试：3、跳过：0、失败：0
使用0x01FC1F1D 进行测试。
扫描测试：4、跳过：0、失败：0
使用0x5533CCAA 进行测试。
扫描测试：5、跳过：0、失败：0
使用0xAACC3355进行测试。
扫描测试：6、跳过：0、失败：0
所有值均已正确扫描。

JTAG DR 完整性扫描测试已成功。

[结束：Texas Instruments XDS110 USB Debug Probe_0]

-乔治

您好、George、

guiquan wu said:

EVM 上是否有其他开关设置未正确配置为"无引导模式"？

将这两个开关设置为"No Boot Mode"(无引导模式)应该是唯一需要的 EVM 配置。

guiquan wu said:

我在目标配置中运行"Test Connection"选项 Debug_Probe 为 soc 板载调试探针创建了"J721E_EVM_XDS110_XDS110_XDS110.ccxml"。

这将是我的下一条建议、以确保 JTAG 连接正常。

guiquan wu said:

JTAG DR 完整性扫描测试已成功。

[结束：Texas Instruments XDS110 USB Debug Probe_0]

[/报价]

但是、日志显示 JTAG 连接没有问题。

您可以检查 JTAG TCLK 频率以确保没有减慢？ 这可能会导致脚本运行得非常慢。

这可以在 Target Configuration 的高级选项卡中找到、方法是单击 All Connections 下的 Texas Instruments XDS110。 然后、在"连接属性"下、确保 JTAG TCLK 频率至少为5.5MHz。

谢谢。

内哈尔

[/quote]

Neehar,

我验证了 JTAG TCLK 频率(MHz)被设定为"固定默认5.5MHz 频率"

以下是我的目标配置的所有设置... J721E_EVM_XDS110_ccxml.ccxml Debug_Probe

高级/所有连接/德州仪器 XDS110 USB Debug Probe_0/连接属性...

板数据文件-自动生成

调试探针选择-仅安装在 XDS110上

电源选择-目标供电电源

电压电平-默认值

JTAG TCLK 频率(MHz)-固定默认5.5MHz 频率

JTAG 信号隔离-在最终断开时隔离 JTAG 信号

JTAG/SWD/cJTAG 模式- JTAG (1149.1、SWD 和 cJTAG 被禁用

仅供参考、我进行了两次和三次检查、以确保 EVM 确实配置为"无引导模式"、其中 SW8和 SW9处于以下状态...

SW8： 1000 1000

SW9： 0111 0000

我希望通过这次会议可以让您对我的设置有更多的了解。

我希望这样可以成功解决此探针在无引导模式下的 EVM 连接问题。

我可以在一天中的任何时间与 TI 合作、在 WebEx 或团队会议中以交互方式解决该问题。

正如我之前所述、这已成为妨碍我推进 C7x 评估测试的一个主要问题。

非常感谢为加快解决这一问题所能做的任何事情。

谢谢。

-乔治

Neehar,

我研究了在连接到 DMSC_Cortex_M3_0时 OnTargetConnect ()调用期间运行的 GEL 脚本的内容。

J721E.GEL 中的 OnTargetConnect()

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_R5LOCKStep.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_DDR32SS\J7_DDR_config.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_DDR32SS\J7-DDR-addr-map-offers.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_DDR32SS\J7-DDR-EVM-LP4-2133_v0.9.1.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_DDR32SS\J7-DDR-EVM-LP4-3733.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_DDR32SS\J7-DDR-EVM-LP4-3733_v0.9.1.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_DDR32SS\J7-DDR-EVM-LP4-4266_v0.9.1.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_OBSCLK\J721E_OBSCLK.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_PADCONFIG\J721E_PADCONFIG.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_PLL\J721E_PLL_MMR.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_PLL\J 721E_PLL_OFC1.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_PLL\J721E_PLL_PARAMS_OFC1.gel

C：\TI\ccs1250\ccs_base\emulation\gel\J721E_DRA829_TDA4VM\gel\J721E_PSC\J721E_PSC.gel

我按照从 J721E.gel 中的 OnTargetConnect ()调用开始的执行流程进行操作,发现在脚本 J721E_PLL_OFC1.gel 中,第43行的脚本顶部附近有一个#define debug 可设置为1以启用到控制台的调试输出以进行跟踪执行。

我更改了此#define debug 1并运行 launch.js、发现该过程 继续超出我之前发布的文章中看到的非调试控制台输出、最后一行是...

DMSC_Cortex_M3_0：GEL 输出：对主 PLL 0 (主 PLL)编程

调试设置为1后、我现在可以看到它继续执行、并最终输出...

DMSC_Cortex_M3_0：GEL 输出：对主 PLL 1 (外设0 PLL)进行编程

进度非常慢、即呼叫至中上述两个步骤之间的时间间隔~3小时 J721E_PLL_OFC1.gel 的 hotmenu Set_All_ L()函数。

至少我已经证明了 GEL 脚本确实在运行，尽管速度有点慢。

我认为速度缓慢不是由于调试标志设置为1引起的。  额外的"调试"控制台输出可能会导致速度缓慢、但我认为整体速度缓慢是由于我的 CCS 设置和/或 EVM 出了问题所致。

我注意到、当 CCS 在每个内部步骤之间以几秒的顺序在 GEL 调用树中移动时、会有稳定的调试控制台输出。  这太慢了,但进展是恒定的。

话虽如此、我发现在 Program_PLL ()的 for-loop 完成迭代之后、在 J721E_PLL_OFC1.gel 内第820行的"等待1us "循环延迟附近的9个 HSDIV 发生了巨大的延迟(~3ish 小时)。

我想知道环路延迟是否是问题的原因。

for (I=0；I<10000；I++)；

此延迟循环是否会以某种方式导致 CCS 的 GEL 脚本解释器 花费极长的时间？

CCS 的 GEL 脚本引擎如何运行？

是否向 GEL 脚本解释器提供了"时间片"？如果可以、是什么时间片？

如果时间片为1秒、则10,000计数的循环延迟可能需要10,000秒=>~167分钟=>~2.8小时。

是否有地方可以更改 GEL 脚本的时间片？

这是由于 CCS 在 Windows 7 64位 SP1上运行造成的吗？

TI 是否在 Windows 7上的 J721E EVM 上测试了这些脚本的 CCS 和 GEL 脚本？

这似乎与我看到的巨大的延迟 Set_All_()的调用设置()之间,这反过来调用 Program_PLL()发生10000延迟循环.

我将让它在夜间继续、此时我应该看到它在执行其他 PLL 编程步骤方面的进展。

如果需要帮助、我可以上传此详细的调试控制台输出、其中显示正在执行的中间步骤。

如果您需要此详细的控制台输出、请告诉我。

我期待 TI 的回应。

谢谢。

-乔治

Needhar,

我让这个 launch.js 和相关 OnTargetConnect ()整夜运行。

我在~18小时的跑步后停止了它。

已经通过如下编程5个 PLL 获得了...

对主 PLL 0 (主 PLL)进行编程

对主 PLL 1 (外设0 PLL)进行编程

对主 PLL 2 (外设1 PLL)进行编程

对主 PLL 3进行编程(CPSW9G PLL)

对主 PLL 4编程(音频0 PLL)

这=每个 PLL 编程~3.6小时。

对于22个 PLL 进行编程、这意味着需要22 * 3.6 =~79小时=~3.3天才能完成。

至少这是荒谬的。

我决定在 J721E_PLL_OFC1.gel：Program_PLL ()第820行中注释掉10000计数环路延迟、然后重新运行测试。

现在,在 Program_PLL()内的 HSDIV FOR-LOOP 编程结束时,不再有一个~3小时的大停顿。

它直接进入接下来的步骤之后,这种 for loop ploding 以每步数秒的名义蜗牛速度进行。

我现在不再见证控制台输出在每次 PLL 编程之间停转~3小时的情况。

我仍然认为大约需要~30分钟才能完成每个 PLL 的编程。

时间因每个 PLL 具有不同的 Num_HSDIV 以进行迭代和编程而异。  我看到它从一些上的9变为另一些上的5。

我确信、CCS 12.5的 GEL 在我的 Windows 7 64位 SP1系统上执行 GEL 脚本的过程非常缓慢。

我看到 CCS Window\Preferences\Run/Debug\View Performance...中有一个设置。

"步骤之间的最小间隔(以毫秒为单位) "... 它被设置为0

我认为这应该是一个不错的设置、但我不确定这是否是控制 GEL 解释器步进的 GEL "时间片"间隔。

这是控制 GEL 解释器步进速度的设置吗？  如果可以、我可以如何设置它、以强制它以更快的速度运行？

我还查看了 Windows 7的任务管理器并检查了分配给两个 ccstudio.exe 进程中每个进程的优先级、两者都设置为"正常"优先级。  我可以将其中一个或两个进程设置为"低"、"低于正常值"、"正常值"、"高于正常值"、"高值"、 "实时"。

显然、"Above Normal"、"High"或"Realtime" 应将更多操作系统时间用于 CCS、但这实际上会改变 GEL 解释器的步进速度。

我不认为必须这样才能使 GEL 运行得更快。

这就提出了一个问题、TI 是否实际上使用此 EVM 及其板载 JTAG 在 Windows 7上测试了 CCS 12.5的 GEL 脚本。

如果这是 CCS 12.5中的一个已知问题、那么 CCS 12.6中也存在、因为在完全卸载 CCS 并重新安装我现在正在使用的 CCS 12.5之前、我在那里也看到了相同的连接问题。

我可以尝试提升这些 CCS 进程的 Windows 7优先级、希望它可以解决这个问题。

它实际上可以满足需要，因为从 Program_PLL ()中消除了10,000个计数的"回路延迟"实际上消除了~3小时的延迟，并且与 EVM 没有交互。  这完全是一个内部 GEL 解释的循环延迟。

这可能不是完整的问题、即、出现延迟的部分原因仍是使用了 EVM 的板载 XDS110调试探针、因为与 EVM 的所有通信必须通过该 EVM 的 JTAG 连接进行。

是否可以将时间戳添加到控制台窗口中发布的每个输出中？

是否有办法将张贴到控制台窗口的内容定向到系统输出文本文件？  目前、我需要定期执行"全选"和"复制"操作、并手动保存到文本文件。  设置这个自动化操作会很有帮助。

请告诉我您对如何推进工作的看法。

谢谢。

-乔治

您好、George、

guiquan wu said:

至少我证明了 gel 脚本确实在运行，尽管进展缓慢。

是的、这肯定会确认正在运行 GEL 脚本。

guiquan wu said:

但我认为整体速度缓慢是由于我的 soc 设置和/或 EVM 完全错误所致。

我怀疑是硬件问题、因为我认为您的软件设置正确。 但是、我们可以检查其他一些事项。 您能否为您提供.ccxml 目标配置文件、以便我确保设置正确吗？ 我在下面附上了我的 示 例、还将附加一段有关如何运行 GEL 脚本的快速视频。

e2e.ti.com/.../J721E_5F00_EVM.ccxml

guiquan wu said:

这就提出了一个问题、TI 是否实际上使用此 EVM 及其板载 JTAG 在 Windows 7上测试了 CCS 12.5的 GEL 脚本。

[/报价]

TI 可能根本没有在 Windows 7上测试 GEL 脚本、因为我们的 SDK 和 CCS 兼容性主要在 Linux 上进行测试和验证。  

guiquan wu said:

是否可以将时间戳添加到控制台窗口中发布的每个输出中？

[/报价]

可以通过一种方法来 调整 GEL_TextOut 函数以包括时间戳。

此外、如果是硬件问题、您是否有其他可以尝试在其上运行 CCS GEL 脚本的电路板？ 或者在其他 Linux 或更新版本的 Windows 10 PC 上运行 CCS？ Windows 7计算机上的驱动程序可能已过时、从而导致 GEL 脚本运行速度非常慢。

谢谢。

内哈尔

[/quote]

e2e.ti.com/.../CCS_5F00_GEL_5F00_tutorial.mp4

Neehar,

这是我的目标配置(我把它拖到这个回复窗口,我看不到它在这里的任何地方)...

我没有另一个 EVM 可供测试、也不认为缓慢是由于 EVM h/w 造成的。

可能是 EVM 硬件坏了、但此时我不认为是这种情况。

我更倾向于认为这是由于 CCS 及其与操作系统的交互、在我的案例中则是与 Windows 7的交互。

我避免了 Windows 7以上的较新版本、因为它们都存在自身的问题、与激进的更新策略有关、这些策略会直接妨碍嵌入式工程工作。

Windows 7与以前版本的 CCS (5、6等)、JTAG 仿真(TI、Blackhawk、 Spectrum Digital)连接到 5个不同的 C6x/C66x EVM 和定制目标生产硬件。

我非常感谢继续使用 Windows 7 64位 SP1。

TI 的最新文档(CCS 等)声称支持 Windows 7 64位、因此我希望它已经过完全验证、可以正常工作。

您的意见：

TI 可能根本没有在 Windows 7上测试 GEL 脚本、因为我们的 SDK 和 CCS 兼容性主要在 Linux 上进行测试和验证。

很遗憾听到这个消息。

显然、认为 CCS 12.5/6和 GEL 已在 Windows 7上充分验证是我所做的不好假设。

TI 不会在 Windows 7上验证 CCS 12.5/6 GEL 脚本吗？

鉴于 TI 到目前为止尚未对其进行验证、TI 是否会在不久的将来某个时间点在 Windows 7上进行此验证测试？

TI 是否最终不再支持 Windows、而是仅支持 Linux？

您的意见：

Windows 7计算机上的驱动程序可能已过时、从而导致 GEL 脚本运行速度非常慢。

您特别提到 TI GEL 脚本所依赖的 Windows 7驱动程序？

关于 Linux、由于最近我们遇到的实际问题、我避免了将 Linux 用作开发平台。

几年前、我们曾试图从 Windows 7切换到 Linux、但发现了很多问题。  下面只是一个很小的子集。

1. Linux/CCS C6000 CGT-tools 在使用相同版本的 C6000 CGT-TOOLS 的 Win7/CCS 上编译失败、而不是无编译失败-我将问题发布到 E2E、没有解决方案。  不用说、我们一直在 Windows 7上进行 CCS 开发。

2. Linux/CCS 的 GEL 脚本不支持在我们的测试环境中使用非常广泛并且在 Windows 上正常工作的 system()调用。

3. Linux 不支持对我们基于 Windows 的工程网络环境中的共享进行可靠访问。

4.我们在针对 Windows (python 和.bat 的组合)的构建脚本上投入了大量资金，这些脚本需要进行清理和移植才能完全支持 Linux。

关于控制台输出时间戳...

您的意见：

可以通过一种方法来 调整 GEL_TextOut 函数以包括时间戳。

请与我分享如何使用 GEL_TextOut 函数获取时间戳。

我希望有一种方法能够在全局范围内启用到控制台的时间戳输出、而无需诉诸蛮力破解代码更改。

关于我之前未回答的问题...  

是否有办法将张贴到控制台窗口的内容定向到系统输出文本文件？  目前、我需要定期执行"全选"和"复制"操作、并手动保存到文本文件。  设置这个自动化操作会很有帮助。

谢谢。

-乔治

您好、George、

guiquan wu said:

只有在目标器件上针对特定 CPU 构建项目代码时、SDK 才起作用。

在 CCS 内的调试目标配置 CONNECT/GEL 执行期间、不需要任何 SDK。

[/报价]

我之所以提供 SDK 支持、是因为 SDK 团队 拥有 CCS 的 GEL 脚本。 如果 Windows 的 SDK 支持有限、则这 包括 Windows 的有限 GEL 脚本/执行支持。

guiquan wu said:

GEL 引擎是否完全嵌入在 soc 运行时本身内？  由什么来控制 GEL 解释器的执行？  GEL 解释器是否依赖 OS 组件？  它们是什么？

CCS 团队会更好地回答这些问题。 请随时在他们的论坛中创建一个主题。

guiquan wu said:

由于我使用 CCS 12.5还是使用 CCS 12.4、这些差异是否会成为新增加的？

这些差异是否会导致出现惰性？

[/报价]

我不这么认为、正如我在发送的视频中那样、我在 Windows 10上使用 CCS12.6、运行 GEL 脚本没有问题。

谢谢。
内哈尔

[/quote]