工具与软件：
您好！
在 SDK 10.1中、我们观察到、当我们尝试通过"rtcwake -s 30 -m mem或""将 EVM (修订版 PROC135E3)进入深度睡眠模式时echo mem > /sys/power/state、DM R5通常(始终是？) 尝试打印断言故障、系统似乎挂起。 在这种状态下、感应电阻器上的功率读数 在唤醒时基本上与这些值相匹配。 在分频器之后、接下来是 SDK 10.1的一些进一步调试详细信息。
在禁用 console_suspend 的情况下、我们看到的其他症状与 processor-sdk-AM62A 相同：SDK 中的 Deep Sleep Error 10.00：首先在 ti_sci_suspend ()中出现邮箱超时 、然后在 e5010_jpeg_enc 内核模块中出现错误 恢复 或者、如果 e5010_jpeg_enc 在尝试睡眠之前被卸载、则会出现进一步的 ti-sci 错误和 MMC 超时。 e5010_jpeg_enc 和 MMC 错误可能只是系统从失败的暂停和尝试恢复中进入不良状态所导致的？
除了 Linux 中的类似症状之外、SDK 10.0和10.1中的 DM 行为似乎也是如此 巨大 :在10.0中,我们没有观察到断言,而 DM 似乎是让它到 WFI (是否 e5010_jpeg_enc 驱动程序是首先卸载的);通过 JTAG 连接到 R5(或随后停用并暂停执行),它的 PC 始终是 WFI 之后的一条指令;大概调试器会从 WFI 唤醒它? 不过、即使 DM 在 SDK 10.0中将其设置为 WFI、感应电阻器上的功率读数也更接近唤醒时的值。
在 SDK 9.2中、卸载 DSP Remoteproc 模块后(由于该版本的 DSP 固件不支持正常关断)、睡眠似乎成功(综合而言、我在检测电阻上读取~20-30mW)、因此这看起来像是 SDK 10.0/10.1中的回归。 在9.2中、不需要卸载 e5010_jpeg_enc 驱动程序、也不会打印邮箱或其它错误。 与 SDK 10.0中一样、通过 JTAG 连接到 R5会显示出该引脚确实绑定到了 WFI。
我们在 EVM 上测试的所有三个 SDK 版本都是 此处的 edgeai 图像、 未进行任何修改。
另请注意、DM 在至少 SDK 9.2、10.0和10.1中似乎有一个占位符版本字符串。
9.2：
##DM Built On: Apr 2 2024 18:17:23 ##Sciserver Version: v2023.11.0.0REL.MCUSDK.MM.NN.PP.bb ##RM_PM_HAL Version: vMM.NN.PP
10.0：
##DM Built On: Aug 13 2024 21:19:51 ##Sciserver Version: v2023.11.0.0REL.MCUSDK.MM.NN.PP.bb ##RM_PM_HAL Version: vMM.NN.PP
10.1：
##DM Built On: Dec 10 2024 20:25:19 ##Sciserver Version: v2023.11.0.0REL.MCUSDK.MM.NN.PP.bb ##RM_PM_HAL Version: vMM.NN.PP
不幸的是、SDK 10.1中的断言消息被截断为~36或37个字符、非常一致、这只足以打印FreeRTOS-Kernel/t发生该断FreeRTOS-Kernel/ta言的文件的""部分、但有一次、它确实成功打印了""、因此断言可能出现在 tasks.c 中
通过 JTAG 检查 R5、一些内核寄存器包含 相关探测字符串的地址、这些字符串可能是声明消息的其余部分：
- R1： 0x9D051194 ->""
FreeRTOS-Kernel/queue.c - R2： 0x9D050E79 ->""
xQueueGiveMutexRecursive - R5： 0x9D0524E6 ->""
vTaskSwitchContext - R6： 0x9D0511AC ->""
FreeRTOS-Kernel/tasks.c - R9： 0x9D04A559 ->""
(uint32_t)(( ( &( pxReadyTasksLists[ uxTopPriority ] ) )->uxNumberOfItems ) > 0)
根据 MCU+ SDK 10.01.00.33中的源代码, R9指向的断言条件似乎是 vTaskSwitchContext()通过调用宏而出现在中 taskSELECT_HIGHEST_PRIORITY_TASK(),因此 这确实是 DM 正在尝试打印的。
我看到日志记录函数使用信标、释放它可能会调用 xQueueGiveMutexRecursive()；可能出现了第二个断言、这 可能是 第一个断言 没有完成打印的原因？ DM 结束在一个紧密循环中轮询堆栈上的内存位置(值为1、与0相比较)；可能是 _DebugP_assertNoLog()或中的一个 forever 循环_DebugP_assert()？
