泰芯TXW81x低功耗开发指南

责任与版权

责任限制

本文档内容仅供参考。珠海泰芯半导体有限公司（以下简称“泰芯”）未对本文档信息的准确性或完整性作出任何明示或暗示的陈述或保证，且不对使用本文件信息所产生的后果承担任何责任。

泰芯保留在不另行通知对本文件进行修改、改进或其他变更的权利。

泰芯没有为客户产品的应用、设计验证提供协助的义务。客户应自行对其应用的设计、验证和测试负责，并确保其应用符合所有法律、法规及安全相关的要求。

如因客户未遵守本协议导致任何损害、费用、损失及/或责任，泰芯不承担任何责任；同时，客户应全额赔偿因客户未遵守本协议而给泰芯造成的任何损害、费用、损失及/或责任。

版权声明

未经泰芯书面同意，任何一方不得为商业目的修改、改编、变更、翻译或基于本文件创建衍生作品。

未经泰芯书面同意，任何一方不得向第三方披露或分发本文件中提及的任何部分或全部源代码、SDK、二进制文件和目标代码。

任何一方不得修改、反向工程、反汇编、反编译或以其他方式试图发掘任何非源代码部分的SDK，包括但不限于预编译的二进制文件和目标代码。

此外，任何可能侵犯泰芯或其他知识产权所有者权利的行为也均被严格禁止。

对于实施上述侵权行为的主体，泰芯有权依据中华人民共和国法律或其他可能适用的法律、国际条约采取必要的法律措施，包括但不限于对侵权人提起诉讼或仲裁，或申请法律强制措施。

珠海泰芯半导体有限公司

2024年09月24日

修订记录

1. 概述

本文是TXW81x低功耗的开发指南和使用说明。TXW81x低功耗支持2种类型方案：单芯片方案和带主控方案：

单芯片方案：TXW81x芯片中实现WiFi功能（低功耗），和音视频功能。

带主控方案：TXW81x芯片中仅实现WiFi功能（低功耗），音视频功能在主控端实现。

本文档主要适用于以下工程师：

• 技术支持工程师
• 方案软件开发工程师

本文档适用的产品范围：

2. 休眠模式

TXW81x SDK支持以下几种休眠模式，请根据方案需求进行选择：

• • 模式1：SYSTEM_SLEEP_TYPE_SRAM_WIFI

休眠时WiFi保持连接，芯片所有SRAM带电，数据不会丢失，唤醒时系统恢复继续运行。

此休眠模式适用于休眠期间保持WiFi连接，同时保持应用程序与云端服务器的连接，支持远程唤醒，且唤醒速度快。

• • 模式2：SYSTEM_SLEEP_TYPE_WIFI_DSLEEP

休眠时WiFi保持连接，芯片只有前32K SRAM带电，其它SRAM掉电，唤醒时系统会复位重新初始化运行。此休眠模式的功耗进一步降低，但是唤醒时需要重新启动运行建立连接。

此休眠模式适用于休眠期间保持WiFi连接，不需要进行远程保活，对唤醒速度要求不高。

• • 模式3：SYSTEM_SLEEP_TYPE_SRAM_ONLY

休眠时WiFi断开连接，芯片所有SRAM带电，唤醒时系统恢复继续运行。

此休眠模式适用于只支持本地过IO或者timer唤醒的场景，休眠后WiFi断开连接，不支持远程唤醒。

• • 模式4：SYSTEM_SLEEP_TYPE_LIGHT_SLEEP

轻度休眠模式，休眠时仅关闭无线收发，CPU正常运行

此休眠模式适用于暂停无线通信，使芯片处于较低功耗同时又保留外围接口正常工作的状态。此模式需要调用system_wakeup API唤醒。

• • 模式5：SYSTEM_SLEEP_TYPE_RTCC

该休眠模式主要实现RTC功能，利用TXW81x内部的比较器比较器，实时检测电源电压VCC33和锂电池的输出电压VBAT。当VCC33小于VABT时，系统进入低功耗模式，CPU停止运行，RTC根据外部晶振计时，芯片只有32K SRAM带电，可以保存数据。当VCC33重新上电后，系统退出低功耗模式，系统重新初始化运行。

此休眠模式适用于掉电后用锂电池供电的系统，为了休眠后节省锂电池功耗，只保留RTC功能，无wifi保活也不保存片内SRAM上的数据。

该模式的外围硬件电路要求如下：

1. 板上需要外接32.768KHz晶振(LXOSCO)，与TXW81x的PA12和PA13相接：

PA12：LXOSCO【低速晶振输出】；PA13：LXOSCI【低速晶振输入】

RTC计时的准确性直接与LXOSCO的精度相关，根据需要选择(如果对精度无要求也可选用内部RC作时钟源)。

1. 选择GPIOA的一个引脚作为P端与电源电压VCC33相接，默认是PA8。
2. 选择GPIOB的一个引脚作为N端的参考电压，默认是PB9。

• • 模式6：SHUTDOWN

即关机模式，芯片通过CHIP_EN管脚拉低之后进入shutdown模式。当CHIP_EN管脚拉高后芯片退出shutdown模式，复位重启然后进入到正常工作模式。

休眠期间TXW81x支持在AP2/PA3/PA8/PA11上输出PWM波形。各种休眠模式的功耗数据见章节“功耗数据”。

3. 休眠与唤醒

3.1. 进入休眠

TXW81x SDK进入休眠的API只有1个：

system_sleep(uint16 type, struct system_sleep_param *args)

所有休眠模式都使用该API进入休眠，只是参数设置不同。

该API参数说明：

• type：设置休眠模式，如休眠模式所述。
• args：设置休眠参数，该参数定义如下：

struct system_sleep_param {

uint32 sleep_ms;

uint8 wkup_io_sel[6]; //sel IO0 - IO5

uint8 wkup_io_en; //0: dis; 1 en

uint8 wkup_io_edge; //0:Rising ; 1: Falling

};

• • • sleep_ms:用于设置休眠的时间长度，单位ms，为0表示不会产生timer唤醒。
    • wkup_io_sel:用于选择唤醒的IO，最多同时支持6路IO唤醒。
    • wkup_io_en:用于使能对应的IO唤醒，0表示关闭对应IO唤醒，1表示打开对应的IO唤醒。bit0对应wkup_io_sel[0]，bit1对应wkup_io_sel[1]，依次类推。
    • wkup_io_edge:用于选择IO唤醒的边沿，0表示上升沿唤醒，1表示下降沿唤醒，IC内部会打开响应的下拉或者上拉电阻。bit0对应wkup_io_sel[0]的边沿设置，bit1对应wkup_io_sel[1]边沿设置，依次类推。

3.2. 唤醒设备

TXW81x的唤醒方式有远程唤醒和本地唤醒（IO,timer，API等）。

• • 远程唤醒：是指App远程唤醒，休眠时WiFi需要保持连接。App远程唤醒时TXW81x会自动恢复运行或reset重启运行。
    • 没有设置唤醒数据的情况下，APP向设备发送任意数据包都会唤醒TXW81x。
    • 设置了唤醒数据之后，App发送给设备的数据会被匹配检查，只有检测匹配到是唤醒数据后才会唤醒TXW81x。使用 sys_sleepdata_request API设置唤醒数据,示例代码可以参考sdk/lib/net/utils/udp_kalive.c中的udp_kalive_init();

SDK默认只支持1种唤醒数据，且唤醒数据最大长度为64 bytes。如果默认值无法满足需求，则可以修改LMAC_WKDATA_SIZE和LMAC_WKDATA_COUNT宏定义的值。在设置唤醒数据时wkdata->count和wkdata->wkdata_size必须设置正确，也就是：

wkdata->count=LMAC_WKDATA_COUNT;

wkdata->wkdata_size=LMAC_WKDATA_SIZE;

• • 本地唤醒：
    • IO唤醒：由IO触发唤醒，TXW81x支持6个唤醒IO，在执行system_sleep时进行设置。
    • timer唤醒：由内部定时器唤醒，进入休眠时内部定时器根据设置的sleep_ms参数进行计数，休眠时间结束时会唤醒芯片。
    • API唤醒：只有SYSTEM_SLEEP_TYPE_LIGHT_SLEEP模式支持API唤醒。
    • 比较器唤醒：TXW81x支持两路比较器唤醒，可以在休眠中设置两个IO作为比较器输入的N端和P端，当比较器输出位0或者1时产生唤醒信号。

4. 唤醒原因

TXW81x被唤醒时，SDK会提供唤醒原因以供查询。调用sys_wakeup_reason API可以查询当前被唤醒的原因。

uint8 sys_wakeup_reason(void);

当前定义的唤醒原因主要有以下几种：

typedef enum {

//timer唤醒

DSLEEP_WK_REASON_TIMER = 1,

//AP Beacon TIM标识唤醒 - 单播数据唤醒，通常是远程唤醒

DSLEEP_WK_REASON_TIM = 2,

//AP Beacon Bcast TIM标识唤醒 - 广播数据唤醒

DSLEEP_WK_REASON_BC_TIM = 3,

//IO唤醒

DSLEEP_WK_REASON_IO = 4,

//由于AP Beacon丢失产生的唤醒

DSLEEP_WK_REASON_BEACON_LOST = 5,

//检测到AP异常产生的唤醒，通常是AP发生了重启

DSLEEP_WK_REASON_AP_ERROR = 6,

//远程心跳超时

DSLEEP_WK_REASON_HB_TIMEOUT = 7,

//唤醒数据匹配唤醒

DSLEEP_WK_REASON_WK_DATA = 8,

//芯片MLCR IO

DSLEEP_WK_REASON_MCLR = 9,

//低电复位

DSLEEP_WK_REASON_LVD = 10,

//PIR 检测唤醒

DSLEEP_WK_REASON_PIR = 11,

//由于AP执行了唤醒命令产生的唤醒

DSLEEP_WK_REASON_APWK = 12,

//AP检测到STA休眠时断开连接

DSLEEP_WK_REASON_PS_DISCONNECT = 13,

//STANDBY模式唤醒

DSLEEP_WK_REASON_STANDBY = 14,

//由于AP检测到STA 保活超时产生的唤醒

DSLEEP_WK_REASON_MAX_IDLE_TMO = 15,

DSLEEP_WK_REASON_STA_ERROR = 20,

DSLEEP_WK_REASON_SLEEPED_STA_ERROR = 21,

//AP休眠时被STA唤醒

DSLEEP_WK_REASON_STA_DATA = 22,

DSLEEP_WK_REASON_AP_PAIR = 23,

} DSLEEP_WK_REASON;

5. 低功耗开发流程

根据实际方案需求选择休眠模式，不同休眠模式的开发流程有所不同，本章节将介绍各种休眠模式的开发流程。请仔细阅读模式1的休眠流程，其它休眠模式与模式1类似部分省略了描述。

5.1. 模式1 - SYSTEM_SLEEP_TYPE_SRAM_WIFI

5.5.1. 休眠唤醒流程

休眠时WiFi保活，而且支持应用程序保活；唤醒时系统恢复继续运行。休眠唤醒流程如下图所示：

如上图所示，在休眠过程中会先挂起应用程序，再挂起设备；唤醒过程中会先恢复设备，再恢复应用程序，同时产生一个event：SYSEVT_SYSTEM_RESUME。

• sys_suspend：挂起应用程序。

在系统进入休眠前，首先执行sys_suspend挂起部分应用程序。受休眠影响的应用程序都需要执行挂起操作，通常是一些网络相关功能模块，进入休眠前停止数据发送。

需要执行挂起的应用代码模块在初始化时使用sys_register_sleepcb函数进行注册，在休眠流程中执行sys_suspend操作时会回调执行注册的回调函数。在回调函数中执行一些挂起操作。

• dev_suspend：挂起设备

在休眠过程的最后阶段会执行dev_suspend挂起设备，备份设备状态信息以便于系统唤醒时能够恢复设备状态。SDK提供的驱动代码都已经支持suspend和resume操作，如果自行添加的外设驱动代码，则需要自行实现suspend和resume操作。

另外SDK提供了dev_suspend_hook接口，在每个device被执行suspend之前会回调该该函数，可以在该函数中对设备进行特殊处理。该函数为weak函数，需要使用该函数时请重写该函数。该函数返回1，表示该device继续执行suspend操作，返回0则终止该设备的suspend操作。

__weak int32 dev_suspend_hook(struct dev_obj *dev, uint16 type)

{

return 1;

}

• dev_resume：恢复设备

系统被唤醒时先执行恢复设备操作，将各个设备恢复到休眠前的状态。

SDK提供了dev_resume_hook接口，在每个device执行resume之前会回调该函数，可以该函数中对设备进行特殊处理。例如根据唤醒原因决定该device是否执行resume操作。该函数为weak函数，需要使用该函数时请重写该函数。该函数返回1，表示该device继续执行resume操作，返回0则终止该设备的resume操作。

• sys_resume：恢复应用程序

设备恢复之后执行恢复应用程序，回调应用程序所注册的回调函数，恢复应用程序运行。

5.1.2. 应用程序挂起和恢复

如上所述，在低功耗开发中需要关注的就是应用程序的挂起和恢复，以及SYSEVT_SYSTEM_RESUME消息的处理。

应用程序的挂起与恢复，需要向系统注册sleepcb回调。相关API定义如下：

回调函数类型 sys_sleepcb：

• 参数type：执行system_sleep API时设置的休眠模式。
• 参数args：挂起或恢复应用程序的参数

struct sys_sleepcb_param {

uint8 action, step;

union {

struct {

uint8 wkreason;

} resume;

struct {

struct system_sleep_param *param;

} suspend;

};

};

• 参数priv：注册sleepcb时的输入参数priv，回调时会传回该参数。

应用程序的挂起与恢复定义了4个优先级，挂起时按STEP1/2/3/4的顺序执行，恢复时按STEP4/3/2/1的顺序执行。

如果某个应用模块需要区分执行优先级则可以在回调函数中判断step值，以区分执行。通常应用程序在step1中执行就可以了，step4 默认用来执行SDK内部协议栈模块的挂起。

5.1.3. RESUME事件处理

芯片被唤醒时会产生SYSEVT_SYSTEM_RESUME事件，需要开发代码处理该事件。查询当前唤醒原因，根据唤醒原因执行相应的代码。

SDK默认已添加了该事件的处理代码，如下：

在sys_check_wkreason函数中查询唤醒原因，执行相应的代码。

示例中的udp_kalive_start()函数是SDK提供的udp保活示例代码，源码位于sdk/lib/net/utils/udp_kalive.c。可参考该示例代码，自行开发所需的保活代码。

udp_kalive.c所实现的功能为：在休眠期间定时醒来向服务器发送保活包，报告设备的状态，保活包发送失败10次时则认为链路断开，唤醒主控。

5.1.4. 单芯片方案

单芯片方案使用WiFi芯片内部的音视频功能，使用FPV SDK进行二次开发。

5.1.5. 带主控方案

在带主控的方案中，主要的业务逻辑均在主控端执行，WiFi模块内部可以执行与服务器的保活行为。

WiFi驱动会在主控端创建wlan0接口，同时WiFi模块内部包含了完整的TCPIP协议栈，也会创建w0接口。设备运行时主控wlan0接口和WiFi内部w0接口，具有相同的MAC地址和相同的IP地址，各自运行不同的应用程序。WiFi模块会识别内部产生的tcp/udp数据流，以判断是WiFi模块内部数据流还是主控数据流。WiFi模块默认只支持识别8路数据流，所以WiFi模块内部的应用程序应控制tcp/udp数据流的数量。WiFi模块打印“NO FREE LOCALID”时表明内部数据流已经超过限值。

可以设置由WiFi模块提前dhcp请求IP地址，主控开机后直接使用WiFi模块申请的IP地址，节省dhcp时间。

当主控通知WiFi模块休眠时，WiFi模块执行休眠流程进入休眠状态。被唤醒时检查唤醒决定是否唤醒主控。主控被唤醒时应主动查询唤醒原因，执行相应的程序。

5.2. 模式2 - SYSTEM_SLEEP_TYPE_WIFI_DSLEEP

在模式2时只有芯片前32K SRAM带电，功耗比模式1进一步降低。进入休眠时WiFi保持连接，支持远程唤醒，但是不支持应用程序保活。唤醒时芯片会复位重新初始化运行，需要重新建立WiFi连接。

5.5.1. 休眠唤醒流程

由于休眠期间不需要应用程序保活，而且唤醒时芯片会复位重新初始化运行，所以休眠流程不需要执行suspend操作。WiFi模块收到休眠指令时，直接进入休眠状态。应用程序数据与状态则直接丢失，唤醒时芯片会复位重新初始化运行。

32K SRAM中有4K区域可以用于保存应用数据，芯片复位时该4K区域数据保持不变。所以应用程序利用该区域存储自定义数据，在系统初始化时读取该区域的数据使用，同时唤醒原因在芯片复位时也保持不变，应用程序可以查询唤醒原因进行相应的处理。

5.3. 模式3 - SYSTEM_SLEEP_TYPE_SRAM_ONLY

在模式3休眠时，芯片所有的SRAM带电，WiFi功能关闭；唤醒时自动打开WiFi功能，系统恢复运行，应用程序继续运行。此模式适用于休眠时不需要WiFi功能的方案。

5.5.1. 休眠唤醒流程

此休眠模式的休眠唤醒流程与模式1类似，区别在于休眠时WiFi功能被关闭。低功耗开发流程与模式1相同。

5.4. 模式4 - SYSTEM_SLEEP_TYPE_LIGHT_SLEEP

此休眠模式为轻度休眠，不支持WiFi保活。休眠时watchdog和CPU仍然在低速运行，可以执行部分简单的用户程序，比如点亮LED，UART数据收发等。

5.5.1. 休眠唤醒流程

此休眠模式的休眠流程与模式1类似，进入休眠时会执行device和应用模块的挂起操作。默认所有的device都会被挂起，可以在dev_suspend_hook函数中保留需要工作的device。例如需要在休眠期间使用uart，则可以在dev_suspend_hook中终止uart的suspend，同时重新设置uart波特率等参数。应用模块也可以类似处理，对不需要挂起的应用模块可以在sleepcb中特殊处理，或者不注册sleepcb。

此休眠模式的唤醒，需要执行system_wakeup API。唤醒时需要重新配置系统时钟，以恢复系统正常运行，WiFi功能自动打开重新建立连接。

5.5. 模式5 - SYSTEM_SLEEP_TYPE_RTCC

5.5.1. 休眠唤醒流程

调用dsleep_rtc_init(uint8 PA_n, uint8 PB_n) API 初始初始化RTC模块,其中PA_n可选范围是PA_0~PA_14, PB_n可选范围是PB_0~PB_14。当检测到电源当VCC33小于VABT时，模组开始`进入模式5休眠，会有打印信息“sys_sleep...”

当检测到VCC33电压恢复正常后，模组退出模式5休眠，打印“soft_reset”，通过dsleep_rtc_get() API可以获取当前的RTC值，返回值类型是uint32，每1/8秒增加1。

6. 功耗数据

以下测试在环境温度25℃，STA打开RX接收AP Beacons时间为1ms、测试电压3.3V、单芯片方案，屏蔽环境下测试。

说明：使用内部32K晶振时，休眠时间越长会带来越大的误差，所以会导致功耗有所上升。

唤醒IO说明

支持的唤醒IO列表

特别说明

1. 建议使用PA0 - PA14作为唤醒引脚：IO0 - IO5唤醒源都支持
2. 默认休眠后只有PA引脚有电压，可以保持。
3. 如果需要PB休眠后有电（VCAM电源域），用dsleep_set_user_giob(user_giob)，设置对应的IO为用户引脚，参数user_giob每一个bit对应一个IO，例如设置user_giob= 0x08是设置PB3为用户IO。
4. PC引脚的设置与PB引脚相同。