This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
您好，我在使用GPTimer边沿中断读取IO数据时，会偶尔发生跳变，例如数据引脚在CLK上升沿发送数据一个bit，28个clk发送完成，在实际使用过程中发现中间某一个位读取的是错误的，且没有规律。举个例子，比如数据引脚上的数据是0x2051810，大部分时间都是读到的0x2051810，但是偶尔会读取到的数据是0x0051810或者0x2051800这类的，错误的数据每次只有一个bit产生变化，或者是从1变成0或者是从0变成1。请问这个是哪里的问题？SDK版本4.30
之前没有遇到类似问题，附上详细的测试数据和测试结果截图
CC2640 GPTimer测试数据.txt您可以看一下，一包数据里面的第二个字符串，是用GPT读取出来的。另外就是GPT的中断处理函数会被其他更高优先级的中断打断吗？
你有没有单独测试用定时器读数据？单独测下看看有没有问题
梦与远方 说：另外就是GPT的中断处理函数会被其他更高优先级的中断打断吗？
会的
单独测试是什么意思？不用系统吗？
只测定时器驱动，不使用BLE协议栈，看下会不会发生数据跳变的情况
怎么做到只测驱动？
将定时器驱动移植到empty例程中进行测试
那我怎么查看采集到的数据呢？错误的数据要一直采集，才会偶尔出现的
偶尔出现确实不好太查，实现起来比较麻烦
最直接办法就是用串口打印，一直打印查看
所以我怀疑是被其他的中断打断了，目前我除了一个GPT的中断之外，还启动了一个定时器，定时发送数据。定时器的中断优先级比TIMERA0中断优先级要高吗？
梦与远方 说：定时器的中断优先级比TIMERA0中断优先级要高吗？
是什么意思，一共几个定时器
开了一个GPT定时器用作数据的读取，然后使用Util_constructClock打开了一个时钟，用于周期性发送蓝牙数据
TIMERA0是硬件中断，优先级比软件定时器中断优先级高
目前我测试过了，如果只开一个GPT中断，然后通过蓝牙发送数据出去，仍旧会出现错误的数据采集，这是不是说明协议栈的中断会打断GPT中断，导致数据采集错误？
集中到一个帖子回复：https://e2echina.ti.com/support/wireless-connectivity/bluetooth/f/bluetooth-forum/204427/cc2640r2f-cc2640r2f-gptimer
