cc2640低功耗模式操作

为了更低功耗,cc2640的串口只会在使用时才开启,不使用时就关闭,但发现频繁的开关会导致程序死掉,直接无响应.以下是我使用的串口开关操作程序:

// 串口号
typedef enum{
UART0 = 0,
UARTCOUNT
} UARTName;
// 流控制所需的配置
static const UARTCC26XX_HWAttrsV2 s_UART_CC26XXHWAttrs[UARTCOUNT] = {
{
.baseAddr = UART0_BASE,
.powerMngrId = PowerCC26XX_PERIPH_UART0,
.intNum = INT_UART0_COMB,
.intPriority = ~0,
.swiPriority = 0,
.txPin = UART_TX,
.rxPin = UART_RX,
.ctsPin = PIN_UNASSIGNED,
.rtsPin = PIN_UNASSIGNED
}
};
// 串口目标
static UARTCC26XX_Object s_UART_CC26XXObject[UARTCOUNT];
static const UART_Config s_UART_Config[UARTCOUNT] = {
{
.fxnTablePtr = &UARTCC26XX_fxnTable,
.object = &s_UART_CC26XXObject[UART0],
.hwAttrs = &s_UART_CC26XXHWAttrs[UART0]
},
};
// 串口句柄
static UART_Handle s_UART_Handle;
// 串口参数
static UART_Params s_UART_Params;

开串口:

UART_Params_init(&s_UART_Params);
// 参数设置
s_UART_Params.baudRate = 57600;
s_UART_Params.writeDataMode = UART_DATA_BINARY;
s_UART_Params.readMode = UART_MODE_CALLBACK;
s_UART_Params.readDataMode = UART_DATA_BINARY;
s_UART_Params.readCallback = UART_ReadCallback;
// 打开串口
s_UART_Handle = s_UART_Config[0].fxnTablePtr->openFxn((UART_Handle)&s_UART_Config[0], &s_UART_Params);
//启动串口局部返回功能为了能在串口接收到数据时及时进回调函数如果没有这条语句将会在缓冲区满时才进入。
s_UART_Config[0].fxnTablePtr->controlFxn(s_UART_Handle, UARTCC26XX_CMD_RETURN_PARTIAL_ENABLE, NULL);
// 开始第一次的读取等待
g_UART_WantedRxBytes = UART_MAX_NUM_RX_BYTES;
UART_Receive(g_UART_RxBuf, g_UART_WantedRxBytes);

关串口:

s_UART_Config[0].fxnTablePtr->readCancelFxn(s_UART_Handle);
delay_ms(10);
// 关闭串口
s_UART_Config[0].fxnTablePtr->closeFxn(s_UART_Handle);

Viki Shi：

一般不用这么折腾，如果使用TI RTOS的例程，程序中无任务后系统会自动进入低功耗模式

user6342616：

回复 Viki Shi:

但是串口一直开启的话应该会有较大的电流吧

Viki Shi：

回复 user6342616:

仅代码来看没发现什么问题，怀疑是内部信号量调度的问题，类似这边这种:
e2e.ti.com/…/471102

user6342616：

回复 Viki Shi:

您给的帖子里的链接不存在了,不知道该如何更改程序

user6342616：

回复 Viki Shi:

程序死掉时调试器暂停调试时显示Break at address "0x1001b988" with no debug information available, or outside of program code.该如何知道程序具体死在哪一行呢

Viki Shi：

回复 user6342616:

那个链接我可以打开，你再试试

Viki Shi：

回复 user6342616:

至于这个报错，请看如下解释：

That message is not an error message. The debugger is telling you that the target is halted at a program address where there is no source code correlation. It could mean one of two things:

1) You are halted in valid code with no symbols loaded for it. This can happen if your project includes a library that has been stripped of all debug symbols. So if you are halted in this library code, you will not have any debug information

2) You are halted at at an address where this is no actual code. This can happen if your code "runs off into the weeds" – basically your code hit some strange exception and jumped to an address that it should not. It could be a stack overflow/corruption, some other memory corruption, some interrupt triggered, etc. In any case, this is typically not a tools (CCS) issue but something specific to the device or program that needs to be debugge

user6342616：

回复 Viki Shi:

停止的地方是 ti_sysbios_family_arm_m3_Hwi_excHandler__I 一直在死循环

Viki Shi：

回复 user6342616:

请根据下面文档的Deciphering CPU Exceptions进行异常排查：
dev.ti.com/…/debugging-index.html

Exception Cause
With the default setup using TI-RTOS, the exception cause can be found in the System Control Space register group (CPU_SCS) in the register CFSR (Configurable Fault Status Register). The Arm Cortex User Guide describes this register. Most exception causes fall into the following three categories.

Stack overflow or corruption leads to arbitrary code execution.
Almost any exception is possible.
A NULL pointer has been dereferenced and written to.
Typically (IM)PRECISERR exceptions
A peripheral module (like UART, Timer, and so forth) is accessed without being powered.
Typically (IM)PRECISERR exceptions
The CFSR register is available in View → Registers.

When an access violation occurs, the exception type is IMPRECISERR because writes to flash and peripheral memory regions are mostly buffered writes.

If the CFSR:BFARVALID flag is set when the exception occurs (typical for PRECISERR), the BFAR register in CPU_SCS can be read out to find which memory address caused the exception.

If the exception is IMPRECISERR, PRECISERR can be forced by manually disabling buffered writes. Set CPU_SCS:ACTRL:DISDEFWBUF to 1, by either manually setting the bit in the register view in the debugger or by including <hw_cpu_scs.h> from Driverlib and calling the following.

#include <ti/devices/cc26x0r2/inc/hw_cpu_scs.h>
//..
int main()
{// Disable write-buffering. Note that this negatively affect performance.HWREG(CPU_SCS_BASE + CPU_SCS_O_ACTLR) = CPU_SCS_ACTLR_DISDEFWBUF;// ..
}