版本信息：

CH58x_BLE_LIB_V1.30                                                                                                          

MESH_LIB_V1.5       

配置信息：

// relay功能

#define CONFIG_BLE_MESH_RELAY                  0

// 代理功能

#define CONFIG_BLE_MESH_PROXY                  0

// GATT层配网功能

#define CONFIG_BLE_MESH_PB_GATT                0

// FLASH存储功能

#define CONFIG_BLE_MESH_SETTINGS               1

// 朋友节点功能

#define CONFIG_BLE_MESH_FRIEND                 0

// 低功耗节点功能

#define CONFIG_BLE_MESH_LOW_POWER              1

// config模型客户端功能

#define CONFIG_BLE_MESH_CFG_CLI                0

// health模型客户端功能

#define CONFIG_BLE_MESH_HLTH_CLI               0

开启了GPIO唤醒功能：

中断处理：

问题：

    GPIO产生中断可能正常进入，但打印不正常，打印的是乱码，并且tmos的事件不处理。但再按一个键，打印就正确了。做一个5S的定时器，定时器一到，这个TMOS事件就会处理。即第一次错，第二次正确，第三次错，第四次正确。

下图中的打印信息，红色线是第一次中断产生的，红色线以下是第二次打印的，第二次正确了。

测得打印输出的波特率偏低，在中断内加延时后，打印的数据正确了。但TMOS事件还是不会处理。

从你描述的这个现象，应该是调用的协议栈的睡眠，第一次按键唤醒后又进入了idle模式，按键第二次才会唤醒，另外tmos任务是禁止在中断中调用的，可以在中断中置一个标志，在主循环中查询标志来调用任务。

做低功耗设计。使用定时器唤醒也是可以解决这个问题的，但这不符合做低功耗设计的需求。有没有方法在中断中取消其进入idle模式？

还有，我只是在中断中抛投event 消息，并不处理event事件，通常的操作系统都是可以这么做的，TMOS不可以这么做吗？

我们的协议栈使用的是rtc唤醒的方式，在等待晶体起振的时候，使用idle模式能够进一步降低功耗，如果使用gpio中断的方式唤醒，可以调用相应时间的延时来等待晶体起振，大概在1.5ms左右，