[参考译文] CC2642R：启用待机模式下的节能策略：工作1分钟后、我们观察到传感器控制器停止收集的数据以及停止计时器(时钟)相关活动

对于我们的新型 MCU cc2642、我找到了一些很好的信息来源：
文件：///C/C：/ti/simplelink_cc13xx_cc26xx_sdk_6_10_00_29/docs/drivers/doxygen/html/_power_8h.html #ti_drivers_convenci_is.c Power_Examples_
和文件 PowerCC26X2.h：它们显示了启用电源策略的多个设置和以下步骤：

您好、Ludmil、

感谢您的咨询。 请帮助我回答以下问题、以便进一步帮助您：

1. 根据我的了解、您一直在使用 CC2640器件、现在将您的代码迁移到 CC2642是否正确？ 还是基于开箱即用示例、这是 CC2642的新软件开发？ 您是否已查看此迁移指南： https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/7.40.00.77/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/porting-guides/cc2640r2_to_cc26x2.html
2. 您能否确认整个传感器控制器功能是否在1小时以上后也停止工作、或者 LED 仅出现故障(之前我已了解了 ADC 和通信(？) 是否也无法正常工作)？
3. 如果未启用备用策略、问题是否会重现？
4. 关于 RCOSC：RCOSC 构建配置不再存在。 要使用 RCOSC、请在项目的预定义符号中添加以下 define：USE_RCOSC。
5. 您知道额外功耗(2倍以上2640)来自何处吗？ 测量 CC13xx 和 CC26xx 电流消耗(修订版 D)可以帮助实现这一点。 您还可以利用 Energy Trace、尤其是 EnergyTrace++指令。

BR、

David

您好、David、非常感谢您的答复。
问题1：是的：我们有一个旧的  CC2640器件、我们将大部分代码迁移到了 CC2642R。 我们使用了 TI 迁移指南和 Simple Peripheral TI 应用中的重用位。

讨论2： cc2642R 产品说明书上显示 p49："IN 待机 模式下、只有 always-on (AON)域处于活动状态。 要使器件恢复工作模式、需要外部唤醒事件、RTC 事件或传感器控制器事件。 …μ A。 所有 GPIO 均锁存在待机模式。"

当周期性 RTC 事件发生时、我们的 SC 代码任务会运行、并通过驱动数字输出来为电压传感器和所有 LED 供电：

gpioClearOutput (AUXIO_O_SG_POWER)；

此后、我们的 SC 代码读取 ADC 以向 MCU 提供电压传感器数据、并安排其自己的执行：
//安排下一次执行  (SC 上的1个采样周期：默认值为100ms)

fwScheduleTask (1)；

所有这一切在以下模式下运行良好：
-标准的"不能通电策略已启用"模式、
-在 WFI 电源管理模式下,
-在待机模式下的前1至3分钟。

在 Power STANDBY 策略模式下的此变量周期1至3分钟后、我们观察到以下情况：
1) 1)我的调试显示所有 LED 均已关闭(红色、蓝色、绿色)、因此我们的 SC 代码尚未进行上述 SC GPIO 调用、或者尚未启用 LED 的电源。
2) 2) MCU 不通过蓝牙报告电压传感器值。 我将调试代码添加到 ALERT 回调函数：scTaskAlertCallback ()、以确认从 SC 到我们的 MCU 固件应用程序的 ALERT 中断已停止。 此外：如果中断可用、我们的 MCU 代码将读取并报告一些 ADC 值：random 或0、但我们看到移动应用中的最后一个值已冻结(没有更多值)、仍然可以连接到我们的器件。
3)蓝牙连接仍然存在、我们 PCBA 上仅由 MCU (而非 SC)控制的单独 IMU 芯片正在向我们的移动应用发送正确的数据。
作为下一个调试步骤、我可以修改我们的 SC 任务以消除可疑的 DIG 输出操作：gpioClearOutput (AUXIO_O_SG_POWER)；


 问题3：如果未启用备用策略、问题是否会重现？  答复：否

关于你的4:感谢信息。 正如我在前面的消息中所示： 我尝试了预定义的   符号 USE_RCOSC、但将 RCOSC_enableCalibration 拒绝为未解析符号。 6.10 SDK 中没有包含在 TI src 代码中、而我们所使用的则是：
#ifdef USE_RCOSC
//设置器件的睡眠时钟精度
#if ( HOST_CONFIG &( CENTRAL_CFG | PERIPHERAL_CFG ))
HCI_EXT_SetSCACmd (500)；
#endif //(central_CFG | peripheral_CFG)
RCOSC_enableCalibration()；
#endif // USE_RCOSC

您的5："您知道额外功耗(2倍以上2640)来自何处吗？  "答复：不、还没有衡量、我们将尝试。 我看了看你提到的文档。 我们没有这样的功率测量设备。 将检查是否可以雇用。

David、您好、我在传感器控制器上进行了另一项测试：没有由我们的 SC 代码驱动的数字输出、没有 ADC 读取、空 SC 任务代码、仅从 SC 生成的周期性 RTC 事件(警报中断)进入主 MCU 固件应用程序内核+我们的 FW 重新安排自身。 此设置 在 MCU 待机模式下成功生成了超过1小时的周期性警报中断。 这里可以看出、这些事件可以单独在待机模式下运行、但由于与 GPIO 上电或断电调用相关的崩溃或死锁、或者与 ADC 相关的固件调用、它们可能会在我们所有 SC 代码运行时停止。  

进一步的调试表明 疑似数字输出的运行情况：
启用然后禁用传感器电源：
gpioClearOutput (AUXIO_O_SG_POWER)；
gpioSetOutput (AUXIO_O_SG_POWER)；

当添加到在电源待机模式下每运行一个采样周期的空(减少) SC FW 应用的开头时、停止向 MCU 发送 SC 警报中断(使用外部晶体、在.syscfg 文件中通过 X 指示)。
我们的空(减少) FW 应用仅包含：生成定期警报中断+通过调用 fwScheduleTask (1)来重新安排 SC FW 任务。

我怀疑 GPIO 调用和 TI 电源管理器运行之间存在竞态条件：在唤醒期间启用数字 IO"、因此我在第一次挖掘操作之前添加了2ms 延迟=> RTC 警报中断已通过我们的 MCU FW 应用恢复并接收。

下一步：我保留了这2ms 的延迟、并将所有固件代码恢复为在电源策略模式下运行=> 2分钟后、警报中断消失、类似于我们在待机模式下的第一个配置。
使用的.syscfg 文件设置如下所示：

SC 电源设置如下所示：

您好、Ludmil、

感谢您提供的额外信息。

是否可以要求您考虑所做的修改(使用驱动程序和传感器控制器)、并使用我们的开箱即用示例之一尝试重现此问题？ 此外、您使用的是 TI 的定制板还是评估板？

BR、

David。

Dave、您好、我的实验使用的配置接近标准 TI 环境：
我使用自定义电路板、但正如我在第一条消息 中所说：我们在编译器预定义符号中使用 power_saving、并且我们启用待机策略的方式与在同一 SDK 6.10.0.29中的 TI FW 应用 simple_peripheral 中启用待机策略相同：屏幕截图中随附的参数比较：

在实验期间、当 SC 警报中断停止时、我无法再进一步减少 SC FW 应用程序、我删除了主代码。 正如我在上面所说的那样、它只具有：
- 2个 digio API 调用
-生成定期报警中断
-通过调用 fwScheduleTask(1)来重新安排我们的 SC FW 任务。

从结果来看、我认为问题与 我们 SC 代码中的2个 digio API 调用有关：它们以某种方式导致 ALERT 中断在待机模式下停止。
我可能需要检查逻辑的效果：我们通过设置 DIG 为传感器和 LED 加电。 输出为0： gpioClearOutput (AUXIO_O_SG_POWER)；

在未启用节能功能以及在 WFI 模式下启用节能功能的情况下、这些 API 可靠运行。 我会再来思考、但目前我无法看到更改我们的主固件和定制电路板将如何解决该问题。  

您好、Ludmil、

我明白了、请允许我在明天之前仔细阅读这些发现、能够对其进行更详细的了解、同时还请求传感器控制器团队专家的帮助、因为目前似乎很难在我们这边重现此问题。

BR、

David。

你好、David、非常感谢。 我 在 simple peripheral 示例 TI 应用和 FW 应用的 syscfg 电源设置中检查了 XOSC 框的使用情况：
设置相同：我们使用并勾选相同的 XOSC LF 和 HF 选项/框：即、外部晶体振荡器用于我们的 PCBA 和 Simple peripheral 硬件：

您好、Ludmil、

谢谢。 我已经与团队进一步讨论了这一点、这似乎不是一个已知问题。 请帮助我了解以下信息：

1. 如果使用具有最少 SC 功能和相同节能设置的 simple_peripheral 开箱即用示例、此问题是否会重现在电路板中？
2. 测试是否在调试模式下运行？
3. 您是否接受过 TI 的定制板审核？
4. 您是否可以在器件崩溃后转储寄存器数据、以便在调试模式下连接到目标来分析一些标志？
   1. AON_RTC 寄存器(SEC/SUBSEC/CH2CMP)- TRM 的第1385页。 完成此操作的目的是检查 RTC 是否已修改(如果 CH2CMP 值大于 SEC 和 subsec、则这种场景会证明可能会导致问题。
   2. AUX_SCE ->CTL 寄存器以查看是否启用了 CLK_EN - TRM 的第1811页。
   3. AUX_SCE --> FETCHSTAT - TRM 的第1812页。
   4. AUX_SCE --> cpustat - TRM 的第1813页。
5. 您可以尝试将默认功率模式设置为"低功率"吗？                                                  

BR、

David。

你好、Daved、你好、5。 尝试将默认功耗模式设置为"低功耗"(对于 SC)：我尝试了2种型号的 SC：使用如下所示的此配置、我无法通过蓝牙连接到我们的移动应用程序、或者很少连接、但 LED 和主电压传感器无法正常工作：

使用第二种可能的型号、我无法通过蓝牙进行连接：

回复：您的问题：
2.是否在调试模式下运行此测试？ LK：我运行在释放模式。 与没有电源策略的释放模式相比、WFI 电源模式在释放模式下运行正常、可以节省32%的功耗。

3.您是否接受过 TI 的定制电路板审核？ LK：TI 尚未审核采用 CC2642R 的更新电路板。  现在、 对于最初 采用 cc2640的电路板来说、我不能这样说：它是8年前设计的。  

尊敬的 David、您好！4： 转储寄存器数据：
我找到了一些读取这些寄存器的 TI 代码、因此我想在从 SC 检测到缺少警报中断后可以在我们的代码中读取它们：

//读取当前 RTC 值
key = scifOsalEnterCriticalSection ();
SEC = HWREG (AON_RTC_BASE + AON_RTC_O_SEC)；
亚秒= HWREG (AON_RTC_BASE + AON_RTC_O_subsec)；

ch2cmp= HWREG (AON_RTC_BASE + AON_RTC_O_CH2CMP)；

关于您的2.： 您是否在调试模式下运行此测试？
正如我所说的、我在释放模式下运行、现在切换到了调试模式、我试图重现该问题并使用串行端口转储 RTC 寄存器。

尊敬的 David、请查看随附的 RTC 日志、其中显示了主 MCU 应用程序代码上的 SC 警报中断事件丢失。 在丢失事件周围的每个采样时刻、RTC 寄存器都会被转储、并在日志中标记"ERROR"(采样周期100ms)。 在不同的照射行程中、至损失事件的时间不同：范围为1-6分钟、一个照射行程中的11分钟不存在问题。  

我们的固件应用在调试模式下运行、我将使用串行端口来生成调试消息。 该应用处于待机电源管理模式。 SC 处于工作模式、因为低功耗模式无法正常工作。

我做了一个快速的健全性检查,无法找到一个明显的问题在 AON ,但需要一个专家来检查。
如果 RTC 没问题、我想用一种场景来说明事件：RTC 滴答没问题。 我们的 SC 任务可能会在尝试 digio 0输出时崩溃(这会停止来自 SC 和 PCBA LED 的电压、我们可以看到并知道相关性)。 我们的 SC 任务无法在下一个 RTC 中断时重新调度自身、并且绝不会再次运行、因此它绝不会再次向主内核生成 SC 警报中断。 我们的主固件发现 No Alert。 这与附加的日志匹配。

e2e.ti.com/.../AON_5F00_RTC_5F00_O_5F00_SEC-log-4-ERROR.txt

收集 RTC 日志时使用的 SYSCFG 和 SC 电源设置：
 

附加的另一条日志：还包括 SC 寄存器(显示的是十进制数)：
误差点：

SC 警报正常 AON_RTC_O_SEC AON_RTC_O_subsec AON_RTC_O_CH2CMP：
23 2295857152 1543048

AUX_SCE_O_CTL AUX_SCE_O_cpustat：
1 1281

错误：SC 警报丢失 AON_RTC_O_SEC AON_RTC_O_subsec AON_RTC_O_CH2CMP：
23 2729050112 1549601

AUX_SCE_O_CTL AUX_SCE_O_cpustat：
1 774
--------------------------------------------------------e2e.ti.com/.../AON_5F00_RTC_5F00_O_5F00_SEC_2B00_SCreg_2D00_s-log-7-ERROR-23-seconds-from-start.txt
似乎失去 SC 警报的时刻是随机的:甚至可以在我们的移动应用程序建立蓝牙连接后23x100ms = 2.3秒。 该应用程序只会在屏幕上显示数据。

您好！

我阅读了这篇文章、您遇到的是代码挂起或实施问题。 另外、我认为电源管理不会导致您的问题。 默认情况下、如果您使用 simple peripheral 设置为 低功耗、则该外围设备将在没有事件时进入待机模式。

我使用 CC2640R2F 集成传感器控制器来完成该项目、从而简化外设。 如果  正确地将传感器控制器集成到了简单的外设、则没有问题。

土壤湿度传感器控制器项目。

-kel

H David、
回复：您的答：下面是我对 RTC 寄存器的解码：从上面的日志7开始：AON_RTC 秒数看起来 总是正确的、包括错误后的错误。 每100ms 出现一个新的日志条目。  围绕错误、我们有全部10个 RTC 秒指示：23、然后数字24正确重复10次。 不会出现任何 RTC 周期丢失。 我们有一个电池测量任务  

回复：您的 b：解码  AUX_SCE --> CTL 寄存器的日志以查看是否启用了 CLK_EN - TRM 的第1811页。
在错误之前和之后的所有情况下、CTL 都为1：因此 会设置 CLK_EN 位、始终启用时钟。

回复：d：以下是我在转换点对 SC cpustat 寄存器的解码：" All GOOD"=>"SC Alert to main lost"：
在所有良好情况下 SC cpustat 中的十进制值1281错误前的"SC Alert OK"：
0101 0000 0001 => 2 bits set：Halted and SLEEP

在所有不良情况下 SC cpustat 中的十进制值为774：错误：ALERT 至 MAIN LOST
0011 0000 0110 => 2 bit set：Halted 和 WEV

关于：wev：这种类型的"写入事件"到被冻结的寄存器-没有完成吗？ 我的日志显示所有后续采样中仍有774个、这是否是所有任务的 SC 崩溃？ 我发现 在错误3秒后：警报中断缺失、我们的另一个 SC 电池监控器任务开始报告0表示电池电压、先前值：几乎充满电池。

H David、
回复：您的答：下面是我对 RTC 寄存器的解码：从上面的日志7开始：AON_RTC 秒数看起来 总是正确的、包括错误后的错误。 每100ms 出现一个新的日志条目。  围绕错误、我们有全部10个 RTC 秒指示：23、然后数字24正确重复10次。 不会出现任何 RTC 周期丢失。  

回复：您的 b：解码  AUX_SCE --> CTL 寄存器的日志以查看是否启用了 CLK_EN - TRM 的第1811页。
在错误之前和之后的所有情况下、CTL 都为1：因此 会设置 CLK_EN 位、始终启用时钟。

回复：d：以下是我在转换点对 SC cpustat 寄存器的解码：" All GOOD"=>"SC Alert to main lost"：
在所有良好情况下 SC cpustat 中的十进制值1281错误前的"SC Alert OK"：
0101 0000 0001 => 2 bits set：Halted and SLEEP

在所有不良情况下 SC cpustat 中的十进制值为774：错误：ALERT 至 MAIN LOST
0011 0000 0110 => 2 bit set：Halted 和 WEV

我删除了 SC 任务源代码的不同部分以进行调试并尝试删除故障、但在所有实验中、我在启动后的随机时刻再现了 SC 警报中断的丢失(即点击 CCS 调试器中的"播放"按钮)。 转换到错误时具有相同的 cpustat 变化：1281 => 774。

关于：wev cpustat 位：这是否是某种类型的"Write Event"到 SC 寄存器、它在错误发生时被冻结？ 写入未完成？
我的日志表明、出现错误后774在所有后续采样周期内仍存在。 这是否是所有任务的 SC 崩溃？ 我发现 在错误3秒后：警报中断缺失、我们的其他 SC 电池监控器任务开始报告0表示电池电压、所有先前的值：几乎充满电池。

您好、Ludmil、

感谢您提供这些信息！ 今天我将与专家一起回顾这些结果、并尽快与您联系。

BR、

David

您好、Ludmil、

WEV 是指"等待事件"指令。 运行时框架不使用这些指令。 您能否确认您使用的是哪个过程会等待某些事件、而这些事件可能根本不会发生、还是过去发生过？ 我建议查看 Sensor Controller Studio 的文档。

您是否有德州仪器(TI)的联系人可以帮助您与我们共享 Sensor Controller Studio 项目文件以便快速查看？

BR、

David。

您好、David、非常感谢您提供的信息。 在 SC 任务代码失败时：我们进行了一个5ms 的计时器调用来延迟我们的 SC 任务代码：fwDelayUs (5000)；。 我昨天删除了这个计时器调用作为一个实验,但我仍然有 WEV 位设置:日志附加。 我们几年前就有一位 TI 联系人、但2022年有人被要求使用论坛。 我们的总部位于加利福尼亚州圣地亚哥。
e2e.ti.com/.../AON_5F00_RTC_5F00_O_5F00_SEC_2B00_log12a-_2D00_5msDelay_2B00_MoreDebug-ERR-500-secs-from-start.txt

Markel、您好、感谢您提供的信息。 我们的 MCU 是 CC2642R。 我们成功运行了相同的 SC 代码几个月、但在.syscfg 文件中未选择电源策略。 当我们在.syscfg 文件中选择"电源策略待机"时、就会发生问题。 您能否提供指向以待机模式运行的简单外设源代码(包括 SC 项目和任务)的链接？

RE 低功耗模式：
SC 电源帮助表指示低功耗模式不适用于 ADC (下面的屏幕截图)、这是正确的吗？ 我们在 SC FW 代码中使用 ADC 启用并选择 API 调用。


正如我在这篇文章中所指出的那样：  

我针对 SC 尝试了2种型号的"低功耗"：使用如下所示的配置、我无法通过蓝牙连接到我们的移动应用、或者很少连接、但 LED 和主电压传感器无法正常工作：

使用第二种可能的型号、我无法通过蓝牙进行连接：

此致

Ludmil

我将 fwDelay ()替换为代码中的硬延迟,仍然观察到与之前相同的错误:冻结的 sc.

//fwDelayUs (5000)；//LK：已删除

对于(U16 n = 0；n < 5000；n++)｛

采样计数器= 0；

}

我在 TI SC 文档中发现该延迟 API 与功耗模式无关：

fwDelayUs

原型：  fwDelayUs(delay)

将下一行的执行延迟指定的微秒数。

为了避免忙等待、使用微秒延迟计时器来实现延迟。

该延迟与功耗模式(工作模式和低功耗模式)以及功耗模式之间的切换无关。

我在 SC 上尝试了自定义/动态开启/关闭低功耗模式：结果相同。
我在 CCS、.syscfg 文件中尝试了"无电源策略"：全部正常：警报在主内核的 Release FW 模式下正常运行。
是否可能设置了 WEV、因为 SC 正在等待来自主内核的 ACK、而此 ACK 不处于待机模式？  我做了一个实验、结果显示：
我在我们的 SC 代码中只留下了警报中断和自我重新安排、尝试了更长时间、通过这个非常减少的 SC 代码、在主内核上失去了警报、这使我认为问题不是来自主 MCU 内核的 ACK。 SC 在此事件上等待、主系统等待提醒、因此我们陷入了死锁。 我们的主要核心 FW 调用 Ack 到 SC 的 API、它在无功耗 Manag 下运行良好。 模式和 WFI 电源管理。 MODE。 也许我可以在主内核上切换到自定义电源模式并 使用该选项。

此致

Ludmil

您好、Ludmil、

似乎您仍然有一个等待事件(WEV)的过程。 请帮我解决以下问题：

1. 在器件崩溃后、从 AUX_SCE --> FETCHSTAT - TRM 的第1812页获取值。
2. 在"sce.lst"列表文件中查找该值(程序地址)、它应该能够告诉您哪个指令导致了 WEV。

   

3. 您能否确认您仅使用来自传感器控制器的 ADC、而不使用 MCU？
4. 您能否分享一下如何读取 ADC 缓冲器(有代码缺口)将会很有帮助。 可能存在生成程序的错误读取风险、从而卡在等待不存在的数据时。

BR、

David。

你好、David、非常感谢、我将负责1。 和2. 内容。

回复：3和4：
3.能否确认您仅从传感器控制器使用 ADC、而不使用 MCU？
在 ALERT 中断显示"数据就绪：在主 MCU 内核上、我们仅调用：AUXADCAdjustValueForGainAndOffset (。 . ) 读取 .output 并调整值。  

4.您能否分享一下您是如何读取 ADC 缓冲器的(有代码缺口)将会有所帮助
LK：我们使用 TI 手册中包含的标准 API：
ADC—Sensor Controller Studio v2.9.0 CC13x2 CC26x2文档

从手册中： 

//选择 ADC 输入
adcSelectGpioInput (AUXIO_A_SENSOR_OUTPUT)；

//启用 ADC
(固定基准、2.7us 采样时间、手动触发) adcEnableSync


 (ADC_REF_FIXED、ADC_SAMPLE_TIME_2P7_US、ADC_TRIGGER_MANUAL)；


//对传感器进行采样并存储 ADC 值 adcGenManualTrigger
()；//禁用 ADC (adcReadcAdcAdcReadValue)；//禁用输出 

--------------------------------------------------------

5年多来、我们的代码序列在上一代 MCU CC2640中成功使用：
adcEnableSync (. . )

对于(U16 n = 0；n < ADC_INPUT_COUNT；n++)｛
//对传感器进行采样
adcSelectGpioInput (Input[n])；

. . . .

. . . .  
U16样片；
adcGenManualTrigger()；
adcReadFifo (样本)；

. . . .；
}

. . . .  
//禁用 ADC
adcDisable()；

我在下面的消息中添加了更多信息

你好、大卫、你的1。 和2：

1. 在器件崩溃后、从 AUX_SCE --> FETCHSTAT - TRM 的第1812页获取值。
2. 在"sce.lst"列表文件中查找该值(程序地址)、它应该能够告诉您哪个指令导致了 WEV

我运行了具有动态功耗控制(启动/停止低功耗模式)的完整 SC 代码变体。 我解码了 FETCHSTAT 并发现：代码中的阻塞位置是在地址00e0处读取的 ADC。 指令代码9990：输入/读取 ADC。 看起来它实际上被前面的 wev1指令阻止。 它在下一条 ADC 输入指令中显示程序计数器：
          ；？ adcReadFifo (样本)；
00df -- EDB1 wev1      #WEVSEL_ADC_FIFO_NOT_EMPTY
00e0 -- 9990 in R1、    [#IOP_ANAIF_ADCFIFO]

请参阅下面随附的所有信息：

一种可能的根本原因解释： 我们正在等待没有发生的 ADC 输入、因为前一个 DIG 输出指令未向我们的电压传感器供电、并且还影响了运算放大器电路(我们的硬件工程师确认了低电压影响)：
DIG 输出未成功：
；？ //启用电源
；？ gpioClearOutput (AUXIO_O_SG_POWER)；
00d0 -- 54bc iobclr #(20 & 0x7)、[#(IOP_AIO0_GPIODOOUT +(20 >> 3))]

上述 DIG 输出的另一个影响：相同的电源路由为我们的 LED 供电、每次发生错误时 LED 都会关闭。  
我们明天还可以尝试用示波器进行确认。

我们仅在 SC 配置中定义了此数字电源引脚、而在主 MCU .syscfg 文件中定义。 但是、仅当在主固件 syscfg 文件中选择了 Standpy 策略时才会出现该错误。  在主 MCU 上和主 MCU 上、在标准非节能模式下都可以正常工作、在 WFI 模式下也可以正常工作。 CC2642数据表：我在49页找到此文本： 所有 GPIO 均锁存在待机模式。

此 DIG 输出在 SC 代码部分中声明、我根据 TI SC 文档明确请求活动模式：
//进入有效功耗模式
pwrRequestAndWaitForActiveMode()；

如果我在 SC 和上述 API 中删除此动态电源控制配置、也会发生该错误。

还附带了 CONFIGs 屏幕截图：.syscfg 和 SC：电源和时钟设置。

我开始使用 adcGetFifoStatus()和 adcPopFifo() 作为变通办法。 将检查 PCBA 上的硬件测试点以确认上述结果。

您好、Ludmil、

此权变措施是否可以避免 SC 停止问题？ 能否确认您未使用 SysConfig 的 DAC 模块？

是否有办法让您与我们共享应用程序的 scp 文件和相关代码？

此致、

David。

尊敬的 David：
昨天在调试模式下、该解决方法运行了65分钟：没有 SC 崩溃。 我今天将在发布模式下测试它、将告诉您。 我将使用随附的.syscfg 和 SC 电源设置：

  

我确认 我 未使用 SysConfig 中的 DAC 模块：以下随附的屏幕截图：

您好、Ludmil、

我懂了。 让我们知道情况如何。

BR、

David。

Dave、您好、我们连接了一个示波器、并确认我的结果对于 SC 上的 DIG 输出是正确的：它在 SC 冻结/死锁的随机时刻停止工作：
gpioClearOutput (AUXIO_O_SG_POWER)；

提醒您：该输出会停止为电压传感器和 LED 供电。 我当时报告过：当我们读取 ADC 时、在 WEV 上会死锁、所以我首先尝试：更稳健的 FIFO 读取：用 FIFO 状态读取代替 adcReadFifo ()并检查状态、重试上述 Dig 输出...等等、所有这些都有所帮助、但 DIG 输出问题仍然存在。  

进一步更改和第二次 SC 冻结：
TI SC 帮助表中指出 ADC 在低功耗模式下不受支持、因此我开始调用 SC 代码：  
pwrRequestAndWaitForActiveMode()；   
然后应用 DIG 输出并执行所有操作、之后切换到低功耗模式。 在主 MCU 代码上、我还在任何 SC 操作开始之前禁用待机模式、并在所有 SC、BLE 和其他操作完成后重新启用它。 我解决了 DIG 输出的冻结问题、但我得到了另一种类型的冻结、请参阅下面屏幕截图中的摘要：

进一步更改和第三次冻结：与第二次类型非常相似：
我用以下看起来相当的菜单选项替换了上述 API pwrRequestAndWaitForActiveMode()：

这是设置的一项更改：在 SC 电源设置中设置"wake up active"选项。 我还从.syscfg 中删除了 SCOSC 校准：这可能不起作用、因为我们使用 XOSC。 33分钟后我观察到 SC 崩溃：
错误：SC 警报 SEC subsec CH2CMP：
2040 2230190080 0

CTL cpustat FETCHSTAT：  
1 1281 1879769235  

FETCHSTAT 1879769235 =>十六进制：700b 0093
lst 文件显示：

PwrRequestAndWaitForActiveMode：
;进入激活模式前更新参考 DAC 时钟分频器
0093 -- 700b ID R7、#(ACTIVE_MODE_SCE_CLK_FREQ_MHz/2)-1)
0094 -- fb96 out r7、[#IOP_ANAIF_DACSMPLCFG0]

我认为在冻结情况2和3中、我们有一个与 DAC 相关的输出操作(与我的情况1：用于控制电源的 DIG 输出类似)。
我想我解决了旧的案例1、但我在不同的开关 TI 代码区域中点击了其他"输出"案例2和3：我如何在 SC 100%的时间内以工作模式工作、而无需切换工作<=>低功耗模式？   
我尝试了 第4种情况：SC 代码中没有切换到低功耗模式、SC 设置中没有动态电源控制：但具有与第3种情况相同的冻结、因为 SC 电源设置中仍然有"唤醒处于活动状态"选项、它会在 TI 代码中引起与上述 PC=0093相同的切换操作码  0093。在 SC 功率设置中使用"init only"选项的第五种情况也会在此处冻结 SC：

FETCHSTAT：700b 0092

PwrRequestAndWaitForActiveMode：
;进入激活模式前更新参考 DAC 时钟分频器
0092 -- 700b ld r7、#(ACTIVE_MODE_SCE_CLK_FREQ_MHz/2)-1)
0093 -- fb96 out r7、[#IOP_ANAIF_DACSMPLCFG0]

我尝试了 SC 上的电源设置：为每个任务代码块设置"活动"、默认电源模式使用任一选项：每次唤醒/仅限初始化时：相同的结果：冻结 SC
存储在.lst 文件中的同一点上、如下所示：
 
PwrRequestAndWaitForActiveMode：
;进入激活模式前更新参考 DAC 时钟分频器
0093 -- 700b ld r7、#(ACTIVE_MODE_SCE_CLK_FREQ_MHz/2)-1)
0094 -- fb96 out r7、[#IOP_ANAIF_DACSMPLCFG0]

我曾尝试在2MHz (SC 设置)处将低功耗和工作模式的频率设置为相同、但 TI 代码中出现了相同的问题：将 SC 冻结在同一地址、操作码略有不同：
PwrRequestAndWaitForActiveMode：
;进入激活模式前更新参考 DAC 时钟分频器
0093 -- 7000 ld R7、#(ACTIVE_MODE_SCE_CLK_FREQ_MHz/2)-1)
0094 -- fb96 out r7、[#IOP_ANAIF_DACSMPLCFG0]

也许我需要.syscfg 中的自定义电源模式？ 或使用约束条件？

您好、Ludmil、

为了进一步帮助您解决此问题、您是否可以尝试以下操作？

1. 您能否确认默认的 simple_peripheral 和/或 SCS ADC 示例(单独或一起)出现了问题？
2. 您是否有可用于重现问题的 TI CC2652XR1 LaunchPad？

3. 试用最新的 F2 SDK (7.10.00.98、上次更新了 SCS)和 SCS (已应用所有补丁)。

所有这些、以便我们可以尝试在 TI 环境中重现问题、从而可以使用基本参考。

BR、

David。

David、您好。谢谢您的建议和 doc 链接、我可以使用 SDK 7.10尝试 SCS ADC 示例、但 从我们当前的 SDK 6.10移植代码/迁移需要一些时间。 我查看了 SC 示例。 看到它们使用的是 RTC。 我 在一些最近的代码更新之前切换到了 Util_restartClock()、这样先在代码中返回 RTC、然后进行测试、再 查看 SDK 7.10。

David、您好、我在我们的应用上运行了 RTC 驱动的测试型号、但最终在读取 ADC 时出现了冻结的 SC 和"等待事件"SC 指令(与第一个问题相同)。

我在 SDK 7.10.00.98和 TI Simple Peripheral 应用中遇到一些编译错误、我正在尝试解决这些错误。

我成功运行了一次成功的测试、使用了减少、几乎为空的 SC 任务、该任务在使用 DIG 输出、ADC 通道和延迟时用于冻结：
使用我们当前的 TI  SimpleLink SDK CC13xx CC26xx 版本6.10.0.29、我成功完成了大约2小时的减少 SC 任务运行、执行了 TI 文档《采用 CC13x2/CC26x2的超低功耗传感应用》、A.3唤醒和睡眠–传感器控制器外加1个额外操作：

-通过调用 fwScheduleTask(1)来重新安排自身在 Init 块和执行块中的周期性 SC 任务。
-仅在执行块调用中：
fwGenAlertInterrupt ()；//主 MCU 应用程序的警报中断- SC 任务与上述 A.3相比的其他操作
fwScheduleTask (1)；//安排下一次执行 、一个勾号100 ms

主 MCU 应用程序执行了与第6节所述相同的 SC 任务初始化和启动。 TI 文档：采用 CC13x2/CC26x2的超低功耗传感应用、A.3唤醒和睡眠–传感器控制器、外加4个其他操作：

1) 1)忽略每个警报中断。 这个主 MCU 内核应用程序仅对该警报中断进行标准确认：
scifClearAlertIntSource()；
scifAckAlertEvents ();
2) 2)在.syscfg 中将电源管理策略启用为"Standby"
3) 3)在跑步过程中连接到手机上运行的移动应用程序
4) 4)驱动周期性的绿色设备 LED、以指示运行成功。

附加了成功测试期间使用的.syscfg 电源部分：

您好、Ludmil、

很高兴听到这个减少 SC 任务的测试可以正常运行。 因此、我们能说在启用 ADC 和使用延迟时出现了这个问题吗？ 您是否尝试过添加更多这些功能、以查看哪个功能生成了问题、并进一步缩小了问题范围？ 此测试仍在您的定制电路板中进行。是否正确(无 TI LaunchPad)？

BR、

David。

您好、David、是的、我使用我们的定制板完成了上一篇文章中所述的测试：未使用 TI LaunchPad。
使用的 SC 电源设置为：

关于：添加新特性：我添加了2个数字 IO 操作：之前在代码中提供的输出用于为电压传感器供电。 我将运行测试。 可让您在周一的午餐时间左右了解结果。

大家好、David、按照惯例：我开始在 SC 主任务中添加几行代码、以查看何时会出现错误：
1)在运行2小时后通过测试正常:这是通过数字输出添加2个开/关电源操作: gpioClearOutput ()和 gpioSetOutput (),没有使用 ADC 操作。 通过 RTC 时钟正常生成定期警报。 我们负责监测 SC 上电池电压的第二项 SC 任务已注释掉、未使用。 我没有调用 SC 上的任何 API 来显式更改活动的<=>低功耗模式。
配置：
在释放模式下的 MCU 主固件上启用电源待机策略(调试模式也运行正常约34分钟、然后我将其停止、下面的 reg)。
SC 配置：默认电源模式活动、在每次 SC 唤醒时应用。 调试跟踪反复显示：

SC 警报正常 SEC 亚秒 CH2CMP：
2497 62259200 163647064

CTL cpustat FETCHSTAT：
1 1281 1879769235

1281 (十进制)为0101 0000 0001 =>位设置：Halted Sleep (这是可以的)

2)第二次测试失败,当我添加 ADC 操作 adcReadFifo(Sample):读取共4个电压到2个 数字输出: gpioClearOutput ()和 gpioSetOutput (),
在器件 LED 关闭且未获得电压的情况下40秒后发生故障、由 RTC 时钟驱动 SC 定期警报/生成。 我们的电池代码在 SC 中添加了注释。 SC 定期警报在40秒后停止。 在释放模式下在 MCU 主固件上再次启用电源待机策略。 SC 配置：默认电源模式活动、在每次 SC 唤醒时应用。

3)第3次跑步和第2次跑步一样:如上所述失败,但在25分钟内。  固件仍处于释放模式。

4) 4)运行失败：在调试模式下与上述配置相同、日志跟踪：SC 警报在大约1分钟后丢失、收集错误日志、调试信息：
错误：SC 警报 SEC subsec CH2CMP：
91 2197946368 6000080
CTL cpustat FETCHSTAT：
1 774 2576351456

SC cpustat 寄存器中的774十进制值、二进制值：0011 0000 0110 =>位设置：暂停 WEV
FETCHSTAT 以十进制数2576351456 =>十六进制值：999000E0     

sce.lst 文件中的 SC 代码：
；？ while (sampleCounter < ADC_MAXIMUM_SAMPLES)｛
/id0149：
00dc -- ea10 CMP R6、#16
00dd -- a606 bgeu /id0150
；？ U16样片；
；？ adcGenManualTrigger()；
00de ----6491 iobset #0、[#IOP_ANAIF_ADCTRIG]
；？ adcReadFifo (样本)；
00df -- EDB1 wev1 #WEVSEL_ADC_FIFO_NOT_EMPTY
00e0 -- 9990 in R1、[#IOP_ANAIF_ADCFIFO]

我有这个错误几周前,并报告它已经在这篇文章: cpustat 仍然显示 Wev,所以在我看来,这是一个假的" non_empty"事件被 SC 代码接收,导致读取一个空缓冲区和一个死锁/冻结 SC 状态。

5)成功运行:通过: 我在 SC 代码中添加了我的变通办法:通过 adcGetFifoStatus()轮询和通过 adcPopFifo(Sample)读取。 我根据 TI 文档进行了这一操作：手动 ADCFIFO 状态检查。 我使用此权变措施重新运行、运行了1小时30分钟、主固件处于调试模式。 与 prev 配置相同。 运行时、仅更改了读取 FIFO API。  

我会继续跑步、并继续添加我们的电池监测器。