工具与软件：
我们使用 SimpleLink SDK CC13xx CC26xx 版本6.10.0.29以及 TI 工具 CCS12：
我们在编译器预定义符号中使用 power_saving、并按照在同一 SDK 6.10.0.29中的 TI FW 应用 simple_peripheral 中启用待机策略的方式启用待机策略：屏幕截图中随附的参数比较： 
当我们在此省电模式下启动固件时、它会运行大约1分钟、此后、从传感器控制器收集的数据停止、并且一些与计时器(时钟)相关的活动也会停止工作。
详细信息：
1) 1)我们对 MCU 中的主处理器使用传感器控制器 RTC 驱动的警报中断。 这些中断/事件调用 ADC 读取操作。
2) 2)对于 LED 开/关调度、我们使用文件 utils.c 中的计时器(时钟) API
util_structClock：它会调用 ti_sysbios_KNL_Clock_built
Util_startClock：调用 Clock_start (handle)以调用 ti_sysbios_KNL_Clock_start
问题1对于 TI：上述区域1)和2)中的故障是否可能是由驱动程序与电源管理器之间的通信出现问题引起的？
依据：《SimpleLink SDK 电源管理：MSP432、MSP432E4、CC13xx/CC26xx 和 CC32xx 用户指南》(2019)
"1.3电源管理器 API
驱动程序开发：设备驱动程序与电源管理器进行通信、以启用/禁用对其外设的访问。 "
上述规格有点旧、 问题2对于 TI：我们的 SDK CC13xx CC26xx 版本6.10.0.29遵循了什么最佳电源管理 TI 规范？ 我们还使用了 TI 规范(下面的链接)、但它适用于更高的 SDK 版本6.40：
software-dl.ti.com/.../power.html
根据我们的电池使用情况测量结果：与使用6.10.0.29的新电流原型相比、我们之前的 TI MCU CC2640节省了2倍：我们还将 power_saving 作为预定义符号。 我们没有包含电源策略选项的.syscfg 文件。 我们在.cfg 文件中定义了待机策略、在新的 SDK 中不再使用此策略。
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 电源设置如下所示： 
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 可靠运行。 我会再来思考、但目前我无法看到更改我们的主固件和定制电路板将如何解决该问题。
你好、David、非常感谢。 我 在 simple peripheral 示例 TI 应用和 FW 应用的 syscfg 电源设置中检查了 XOSC 框的使用情况：
设置相同：我们使用并勾选相同的 XOSC LF 和 HF 选项/框：即、外部晶体振荡器用于我们的 PCBA 和 Simple peripheral 硬件：
您好、Ludmil、
谢谢。 我已经与团队进一步讨论了这一点、这似乎不是一个已知问题。 请帮助我了解以下信息：
BR、
David。
你好,大卫,感谢你的建议。 您的问题5. 您可以尝试将默认功率模式设置为"低功率"吗？ 我将在今天尝试。 我想要这样做、但在 SC 电源帮助表中注意到低功耗模式不适用于 ADC (下面的屏幕截图)、是这样吗？ 我们在 SC FW 代码中使用 ADC 启用并选择 API 调用。 
重新讨论您的1。 如果使用具有最小 SC 功能的开箱即用 simple_peripheral 示例：
我想这么做、但我只有一个简单的外设项目文件、其中没有 SC 文件、并且不使用传感器控制器：
simple_peripheral_CC26X2R1_LAUNCHXL_tirtos_ccs
如果您知道使用 SC 代码的简单外设型号的链接、并提供了 SC 工程、则会很有用。
我必须搜索此类工程才能查看 SC 源代码。
你好、Daved、你好、5。 尝试将默认功耗模式设置为"低功耗"(对于 SC)：我尝试了2种型号的 SC：使用如下所示的此配置、我无法通过蓝牙连接到我们的移动应用程序、或者很少连接、但 LED 和主电压传感器无法正常工作： 
使用第二种可能的型号、我无法通过蓝牙进行连接： 
回复：您的问题：
2.是否在调试模式下运行此测试？ LK：我运行在释放模式。 与没有电源策略的释放模式相比、WFI 电源模式在释放模式下运行正常、可以节省32%的功耗。
3.您是否接受过 TI 的定制电路板审核？ LK：TI 尚未审核采用 CC2642R 的更新电路板。 现在、 对于最初 采用 cc2640的电路板来说、我不能这样说：它是8年前设计的。
收集 RTC 日志时使用的 SYSCFG 和 SC 电源设置： 
Markel、您好、感谢您提供的信息。 我们的 MCU 是 CC2642R。 我们成功运行了相同的 SC 代码几个月、但在.syscfg 文件中未选择电源策略。 当我们在.syscfg 文件中选择"电源策略待机"时、就会发生问题。 您能否提供指向以待机模式运行的简单外设源代码(包括 SC 项目和任务)的链接？
RE 低功耗模式：
SC 电源帮助表指示低功耗模式不适用于 ADC (下面的屏幕截图)、这是正确的吗？ 我们在 SC FW 代码中使用 ADC 启用并选择 API 调用。
正如我在这篇文章中所指出的那样：
我针对 SC 尝试了2种型号的"低功耗"：使用如下所示的配置、我无法通过蓝牙连接到我们的移动应用、或者很少连接、但 LED 和主电压传感器无法正常工作：
使用第二种可能的型号、我无法通过蓝牙进行连接：
此致
Ludmil
您好、Ludmil、
似乎您仍然有一个等待事件(WEV)的过程。 请帮我解决以下问题：
BR、
David。
你好、大卫、你的1。 和2：
我运行了具有动态功耗控制(启动/停止低功耗模式)的完整 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：电源和时钟设置。
尊敬的 David：
昨天在调试模式下、该解决方法运行了65分钟：没有 SC 崩溃。 我今天将在发布模式下测试它、将告诉您。 我将使用随附的.syscfg 和 SC 电源设置： 
我确认 我 未使用 SysConfig 中的 DAC 模块：以下随附的屏幕截图： 
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 中的自定义电源模式？ 或使用约束条件？
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 电源部分： 
您好、David、是的、我使用我们的定制板完成了上一篇文章中所述的测试：未使用 TI LaunchPad。
使用的 SC 电源设置为： 
关于：添加新特性：我添加了2个数字 IO 操作：之前在代码中提供的输出用于为电压传感器供电。 我将运行测试。 可让您在周一的午餐时间左右了解结果。
