CC1312R: CC1312在空中升级例程中加入SENSOR小核程序，但是小核唤醒大核时间不正常

是bim的程序影响了小核的运行么？

是的，我已经在一个普通例程中实现了我得应用程序的所有功能，sensor定时唤醒大核，大核被唤醒后会发出一些数据，发送完成后进入休眠模式（低功耗）；

因为我需要在原来的基础上假日OAD空中升级工能，于是我将我得应用程序移植到了OAD例程中，在验证的时候遇到了这个唤醒异常的问题。

我在验证过程中将所有有可能唤醒大核的途径全部屏蔽掉了，仅剩如下

如果我将fwGenQuickAlertInterrupt();这一句屏蔽掉，大核就不会再被唤醒。如果加入该函数，就大核不会按照cfg.threshold=10；fwScheduleTask(cfg.threshold);10秒唤醒一次的周期进行唤醒，而是不停地唤醒，具体周期没有测试，但确定是不足1秒就会大核就会被唤醒。而且无论我将cfg.threshold改成多少对唤醒频率并没有什么影响

你能告诉我你是如何知道设备正在唤醒的吗？是通过监测功耗还是采用其他方法？（即使你从应用中移除其他唤醒诱因，设备仍可能基于电源驱动、射频堆栈或类似机制自行唤醒。）
你能指给我看在Sensor Controller Studio中输入10秒值的位置吗？确定它没有被误认为是10毫秒或10个时钟周期吗？

我使用一模一样的应用程序在rfPacketTx例程中使用了很久了，一直都很正常。也做过很多测试。但是移植到OAD例程里面就出现了这种问题。

Vivian Gao 说：

即使你从应用中移除其他唤醒诱因，设备仍可能基于电源驱动、射频堆栈或类似机制自行唤醒。

关于这三种可能性如何排除其因素呢？

目前我也只是觉得sensor异常唤醒的可能性比较大。

我进一步排查了一遍如果我不对小核进行初始化，保留其他所有的程序内容不变，

存在异常唤醒时得引脚波形

没有任何唤醒时一直是低电平，10秒唤醒一次不会出现这么密集得高低电平得切换

好的，这样就明白了。
你能指给我看在Sensor Controller Studio中输入10秒值的位置吗？你确定它不会被误认为是10毫秒或10个计数吗？

这里有一个

#define COLLECT_TIMER               10

然后引用我这个函数

sensor_controller_init(COLLECT_TIMER);

void sensor_controller_init(uint8_t num)

{

  //Initialize the AcquisitionInt

  scifTaskData.temSensor.cfg.threshold = num;

  // Initialize the Sensor Controller

  scifOsalInit();

  scifOsalRegisterCtrlReadyCallback(scCtrlReadyCallback);

  scifOsalRegisterTaskAlertCallback(scTaskAlertCallback);

  scifInit(&scifDriverSetup);

  scifStartRtcTicksNow(0x00010000);

  scifStartTasksNbl(BV( SCIF_TEM_SENSOR_TASK_ID));

}

小核里面也有设置这个值10，其他地方未做任何的修改。只有这几处涉及这个变量的修改

这样达到10s的一个唤醒频率，这个程序我在之前的rfPacketTx例程中使用过，原本是想让小核按照10秒一个周期运行，运行6次唤醒大核一次，实现1分钟发一次，虽然不是特别精确但是1分钟左右不会超过3秒的误差正常运行的，我现在为了避免其他的程序影响直接简化为10秒运行一次直接唤醒大核，这样修改过的程序我也在原本程序中验证过了。没发现问题，但是当在OAD例程中做出修改后就出现这种问题了。而且我的OAD程序和应用程序没有同时打开，只是在启动时只选择一个线程运行，另一个线程不启用，不知道为什么会影响小核唤醒大核的周期

我昨天尝试过修改#define COLLECT_TIMER               10       这个值的大小     scifStartRtcTicksNow(0x00010000);还有这个参数中的值的大小观察小核唤醒大核频率是否有改变，最终结果是这两个值无法影响小核的运行周期了，也不会改变小核唤醒大核的周期频率。

我们能再次确认确实是传感器控制器唤醒了系统CPU吗？
你发布了一张引脚波形的照片。我猜这是CONFIG_GPIO_LED引脚吗？程序中其他地方没有对它进行切换操作吗？
你能检查一下信号量semScTaskAlert的语法和实现吗？这是一个计数信号量吗？你能查看第一次调用GPIO_write时它被发布了多少次吗？

我非常确认是传感器控制器唤醒了系统CPU,

CONFIG_GPIO_LED这确实是一个引脚，只有在系统CPU被唤醒后运行一次这个引脚会切换高低电平，

我在这里也已经提到了，屏蔽了传感器控制器的初始化，就不会再被唤醒了，一次都没有被唤醒，这是验证是不是被传感器控制器唤醒的最简单最便捷的方法。与其花大量时间寻找其他的唤醒原因的可能性，我个人觉得不如直接屏蔽//sensor_controller_init(COLLECT_TIMER);这个初始化观察是否还会被唤醒；

我得结果是只要传感器控制器没有被初始化(小核不再运行)系统CPU就不再被唤醒了。这不就说明唤醒源就是出在传感器控制器么

zjj12138 说：

 //sensor_controller_init(COLLECT_TIMER);sensor初始化函数屏蔽掉，就不会出现异常唤醒了。

Vivian Gao 说：

semScTaskAlert的

这里是这样写的，移植过来后我尽可能的保持完全不变，因为之前应用程序是验证过的，只是不知道OAD例程是不是真的会影响传感器控制的的运行。