[参考译文] AM625-Q1：ClockP_getTimeUsec 在 CCS 调试中返回异常值

您好、 Tony、

这个线程似乎被分配到了不同的 RO、再次、它被分配给了我的名字。

我正在查看您的查询、您可能希望在一天结束前得到答复。

此致、

Anil.

你好,这个问题是我要求 Tony 提交. 这是关于在 A53ss1-0 内核上运行的裸机‑Ω 金属程序。 我发现在调试模式下调试程序时、调用ClockP_getTimeUsec()函数会返回异常的微秒级值、ClockP_sleep函数的延迟时间也是异常的。 我怀疑这是由时钟节拍计数溢出引起的。

您好、 Tony、

您能否确认您正在 A531_0 内核上运行 FreeRTOS/NORTOS？

从 CCS 加载示例时、时间是其他 A53 内核正在运行还是不从 CCS 加载？

是的,如果柜台溢出,那么可能会有一个机会,我们可能得到一个大数字。

不要使用 32 位计数器、而是使用 GTC 计时器、仍然可以查看您是否遇到相同的问题。

因为 GTC 计时器是 64 位计时器、并且 GTC 计时器在~1490 年后溢出。

此致、

Anil.

在 A531_0 内核和 运行 SDK hello_world 示例的其他 A53 内核上运行 NORTOS

您好、

很抱歉、回复延迟。 在过去的几天里、我与内部团队会议联系在一起。

我回顾了所有 A53 示例、每个 A53 内核都使用自己的计时器实例。

内核之间没有计时器共享、因此不会出现另一个内核的滥用或干扰。

异常时序看起来像是计数器溢出问题、而不是软件中的任何功能问题。 由于 计时器以 25MHz 运行、因此它将大约每~2 分钟溢出一次。  

为避免这种溢出、最好改用 GTC（全局时间计数器）。 您可以直接从 SysConfig 启用 GTC 计时器。 启用它后、从 GTC 寄存器中读取 64 位计数器值。 GTC 计数器实际上不会为您的用例溢出、因此时序测量保持稳定和准确。

此致、

Anil.

您好：
当我通过串行端口将此代码刷入板载闪存并正常运行（而不是在调试模式下）时、它工作正常并且没有溢出。
您是否曾尝试使用 SK-AM62 EVM 及其板载 XDS110 来调试“Hello world“程序？
在这块电路板上、当我在调试模式下运行“hello world“程序并额外读取返回的值时ClockP_getTimeUsec()、我还会观察到异常行为。

您好、

我没有在我这边进行测试、根据上述信息、我仍然认为这个问题可能是与 32 位计时器溢出有关的。

我可以在我这边确认。 同时、如果由于该 32 位计时器而不是该计时器、您在测量时卡住或面临问题、请使用 64 位 GTC 计时器。

我可以在我这边进行检查、告诉您星期一的状态。

此致、

Anil.

您好：

我无法重现我这边的问题、示例代码在我这边运行正常。

附加了代码以供参考。

我觉得、根据上述结果、不同的 A53 内核中使用了相同的 UART。

您需要做一件事：使 UART 在 A53_1_0 内核中运行、并在所有其他 A53 内核中保持 UART 禁用状态。

并且、请确认测试结果。

/cfs-file/__key/communityserver-discussions-components-files/791/hello_5F00_world_5F00_am62x_2D00_sk_5F00_a53ss1_2D00_0_5F00_nortos_5F00_gcc_2D00_aarch64.zip

此致、

Anil.

e2e.ti.com/.../temp.mp4
你好

如视频所示、您可以看到我已导入您提供的工程、并且我正在通过调试模式将程序刷写到 DDR 中来运行程序。
首次进入调试模式时、程序正常工作：打印正常运行、返回正确的值、断点按预期命中。
但是、在调试模式下重置器件并重新加载固件时、程序会异常运行：打印无法正常工作、无法进入断点、而正如视频所示、断点会卡住。

我怀疑在调试模式下、在 IDE 中复位器件后、SOC 的时钟变为异常。 这会使DebugP_log API 等待信标、并且由于时钟节拍异常、这会导致无限延迟。 此外、此问题会导致ClockP_getTimeUsec检索异常节拍计数、使返回值看起来就像溢出一样。

您好 、您好、

当我们执行 CPU 复位时、只会将 CPU 寄存器清零。
所有其他系统组件继续保存其先前的状态和内存内容。

在此流程中、我们将执行 CPU 复位、然后再次加载示例。

在正常条件下、内核应该启动并按预期运行。

但是、重置后、所有驱动程序和 GIC 将再次初始化。
由于这种重新初始化、未接收预期的信标信号、这会导致第二个加载中的同步不正确。

需要仔细检查该序列、以了解为什么当 CPU 复位后第二次加载时该示例无法正确运行。

默认情况下、内核应从地址 0x700000044 开始执行、但在 CPU 复位后、再次加载示例时、它会从 0x70000040 开始。

此行为需要进一步调试、但不会影响您当前的开发。

如果要重新加载示例、请使用 SYSTEM_RESET 并加载示例。

但是、如果从 CCS 中执行 System_reset 并反复加载示例、则不会出现问题。

重要的是、该问题与 A53 时钟配置无关。

您可通过每次读取 A53 内核时钟来确认这一点、时钟保持准确。

此致、

Anil.

我正在使用 SK-AM62B-P1 EVM、 如视频所示、当我使用系统复位功能时、调试会话会显示芯片进入自由运行模式、调试器无法再连接到芯片。 从串行日志中、我可以看到芯片确实已完全复位、但它从引导加载程序开始运行、从闪存重新加载程序、这会使我通过调试器加载的程序无效。 因此、我需要重新启动调试会话并再次进入相同的有问题的无限循环。
根据您的回复：“默认情况下、内核应从地址 0x700000044 开始执行、但在 CPU 复位后、当再次加载示例时、它从 0x70000040 开始。“ 我发现、在正常的 CPU 复位后、尽管它从 0x70000040 开始、但点击“run"会“会使它在 0x70000044 停止。 但是、加载程序后、也会卡住等待 semaphore.e2e.ti.com/.../2025_2D00_11_2D00_26-10_2D00_15_2D00_37.mp4

您好 、您好、

建议的程序（临时权变措施）

请按照以下步骤操作：
1.加载示例并运行一次。
加载示例并开始运行后、断开调试器。
2.执行系统重置。
3.重置后重新连接调试器。
4.重新加载示例并运行。

使用此序列、您将能够从 CCS 重复加载和运行示例、而不会出现问题。
这只是一个临时过程来取消阻止您。

我们已经确定当前的行为不是预期的—这是一个错误,需要修复。

请查找随附的视频以供您参考。

/cfs-file/__key/communityserver-discussions-components-files/791/A53-Load-.mp4。

此致、

Anil.

您好、我在 SK-AM62B-P1 EVM 上测试了此临时权变措施、它运行良好。 遗憾的是、在我的定制 PCBA 上、尝试“系统复位“不会按预期重置器件。 相反、它会使芯片进入 UART 引导模式、在此模式下处理器等待通过串行接口上传固件。 因此、“系统复位“功能不可用。 此问题可能是我使用 SOIC-8 引脚 QSPI 闪存的 PCBA 导致的、该闪存缺少专用的硬件复位引脚。

您好、正如您提到的、“我们已确定当前行为不符合预期—这是一个错误、需要修复。“ 您能否提供解决此问题的预计时间表？ 如果修复过程有任何进展、请通过 E2E 勾选或发送电子邮件至laixiangjian@appotronics.com 更新我、以免因维修时间延长而忽略问题。

您好 、您好、

您好、正如您提到的、“我们已经确定当前行为不符合预期—这是一个错误、需要修复。“ 您能否提供解决此问题的预计时间表？ 如果修复过程有任何进展、请通过 E2E 勾选或发送电子邮件至laixiangjian@appotronics.com 更新我、以免因维修周期延长而忽略问题。

是的、需要在 MCU+SDK 中修复这个问题。

实际上、CPU 复位和加载示例不会产生问题。

但我们只在 A53 内核中看到这个问题、其他内核（如 R5F 和 M4F 内核）也不存在同样的问题。

我提出了 JIRA 来解决这个问题、我认为它大部分会在下一个版本中出现、即 2026 年 3 月。

从开发团队获得完整的详细信息后、我将更新时间表上的状态。

此致、

Anil.

供参考：区别在于：

断开连接->系统复位：工作正常、可以重新连接、加载和运行。

Halt ->系统复位：不起作用、导致无法连接 JTAG。

实际上、CPU 复位和加载示例不会产生问题。

但我们只在 A53 内核中看到这个问题、其他内核（如 R5F 和 M4F 内核）也不存在同样的问题。

我提出了 JIRA 来解决这个问题、我认为它大部分会在下一个版本中出现、即 2026 年 3 月。

是否讨论了 Jira？ 是否有目标到期日？ 由于 QSPI 闪存没有复位引脚、因此调试定制板不方便。 不会通过热重排引脚重新旋转电路板来为 QSPI 闪存供电以控制电源开关、但这过于复杂且需要时间。

如果可以在短时间内解决问题、则可以节省能源。 。