[参考译文] LAUNCHXL-CC1352P：cc1352

您好 Luigi Desiderato、

我希望你做得好。 看看 PRCMDEEPSLEEP 功能、它与器件进入低功耗模式(SLEEP)相关、并且从您描述的角度来看、它永远不会唤醒。 首先、我想问一下您如何修改传感器控制器项目、您在哪个 SDK 上开发的、CCS 版本以及您使用的是定制电路板还是 LaunchPad？

谢谢！
Alex F

Alex、您好！答案：
1)我设计了一个以低电平运行的采集方案、如下所示：在计时器中断(tick = 100ms)之后、在第一个任务初始化中初始化、其回调仅使用 I2C_transfer 进行编码。 此事务处理的是 在任务初始化时通过回调模式(和400kHz 数据速率)打开 μ I²C 和 I2C_transfer 结构所获得的句柄(从未出现 i2c 事务错误！)。 因此、当 i2c 事务终止时、驱动程序的回调允许我获取读取的数据、然后将其放入循环缓冲器、然后发布信标 S1。 由于这个模型由中断驱动、所以它以最高优先级运行、但是完成它(并减去 RTOS 和运行任务)所用的时间非常短、每100ms 最多几十微秒。 在任务级别、我修改了原始 readSensors、使用测试上述信标 S1的程序、如果被阻止、该函数就会退出、不能在无线电上传输后续数据、因为输出缓冲区中可用于该数据的空间根本不存在(因为 sensor.frameControl 中的相对位 关闭)、并且 processSensorMsgEvt 的传输仅针对 sensor.frameControl 位可用的情况运行。 当信标 S1开启时、这意味着一些数据已经由刚刚提到的底层机制获取、在这种情况下、这些数据直接加载到 processorSensorMsgEvt 的输出缓冲区中 、以便无线发送。 sendSensorMessage 执行的传输始终会正确终止、并且在 sensor.frameControl 中的相对位上升(该位在数据被处理后恰好下降)后、实际上会由另一个设备通过无线方式接收数据。 所有这些看起来都正常工作、但在~4个周期后、sensorProcess 在 ApiMac_processIncoming 中的信标 appSemHandle 上停止。 只有当 sensor.frameControl 不再有其他活动要完成时,才调用最后这个函数为 Sensor_Process ,但是它的第一个语句是一个使进程停止的"SEM_WAIT (&appSemHandle )"。  我还插入了一个看门狗、用于检查代码是否有问题、失速始终会在 ApiMac_processIncoming 中发生。 信标 appSemHandle 也被释放,当一个用户界面事件是由 CUI 键盘捕捉机制引起的,(我真的不知道为什么这是在 ApiMac 功能内处理)但如果你不在键盘上操作,停顿发生,我不知道为什么,因为我从原始代码的变化正是我在这里提到的。 请注意、即使该过程停止、采集机制显然仍在运行(应该是由中断驱动的！) 但当循环缓冲区已满时、不会进一步存储数据、后续采集肯定会丢失。 循环缓冲区过维、不存在问题。 运行原始传感器代码不会发生失速。
2) 2) SDK 为 simplelink_cc13xx_cc26xx_sdk_7_41_00_17
3) 3) CCS 版本为 12.4.0.00007
4) 4)我使用定制电路板、但 LaunchPad 上也会出现同样的问题、因为两个电路板使用的 I/O 完全相同、并且 I²C 线也来自 Launchpad 上的自由扩展 I/O。
实际上、我正在尝试跟踪 ApiMac_processIncoming 中发生的情况(这真的很乏味)、以检测是否存在允许失速的隐藏条件、但这会导致巨大的时间损失、从而延迟工作的完成。
如果您有一些想法... 提前感谢。
真诚的路易吉

路易吉您好！

感谢您的详细答复！  

您是否已尝试分隔 I2C 任务？ 我说的这句话是指尝试将 I2C 任务放在一个不相关的工程(假设是一个空工程)中、并在该工程中运行任务、看看我们是否存在任何问题。 这可以告诉我们 I2C 任务不是问题、而可能是我们需要进一步研究的 Sensor 项目中的内容。  

谢谢！
Alex