TI中文支持网
TI专业的中文技术问题搜集分享网站

CC1310: 设置CC1310为长接收模式(bRepeatOk以及bRepeatNok都为1),在RF接收到数据后通过串口输出正常,但是串口收到数据后RF切换发送之后异常(调用RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, NULL, 0);导致设备重启)。

Part Number:CC1310

我现在的项目是CC1310上电为长RX状态,在收到数据后通过串口输出信息,串口收到外部指令后会取消当前RX状态切换为TX并且发送数据,发送完成后继续长RX模式。现在RF接收没有问题,但是一旦取消RX命令后调用RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, NULL, 0)会导致设备重启,我通过调试确定取消状态成功。感觉重启像是概率性的问题,因为我有多块我们自己的板子,有一块能够正常执行TX命令,但是其他的无法发送调试发现每次调用RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, NULL, 0)后重启。

以下是一些配置代码:

if( RFQueue_defineQueue(&dataQueue, rxDataEntryBuffer, sizeof(rxDataEntryBuffer), NUM_DATA_ENTRIES, MAX_LENGTH + NUM_APPENDED_BYTES)){ /* Failed to allocate space for all data entries */ while(1); }
/* Modify CMD_PROP_RX command for application needs */ /* Set the Data Entity queue for received data */ RF_cmdPropRx.pQueue = &dataQueue; /* Discard ignored packets from Rx queue */ RF_cmdPropRx.rxConf.bAutoFlushIgnored = 1; /* Discard packets with CRC error from Rx queue */ RF_cmdPropRx.rxConf.bAutoFlushCrcErr = 1; /* Implement packet length filtering to avoid PROP_ERROR_RXBUF */ RF_cmdPropRx.maxPktLen = MAX_LENGTH; RF_cmdPropRx.pktConf.bRepeatOk = 1; RF_cmdPropRx.pktConf.bRepeatNok = 1;
RF_cmdPropRx.rxConf.bAppendRssi = 1;
RF_cmdPropRx.rxConf.bAppendStatus = 0;

取消调用的函数:RF_cancelCmd(rfHandle, rfCmdHandle, 0);//终止接收

发送调用的函数:RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, NULL, 0);

?? ?:

补充下:我用的SDK是     simplelink_cc13x0_sdk_4_20_02_07, 代码编译环境为IAR

,

Yolande Wang:

您好,

1.首先检查代码是否内存溢出,确保 TX 命令执行后没有发生内存溢出的情况

2.时序:确保在调用RF_runCmd之前,RF 配置已经完成且与 TX 操作相匹配。

如果以上未能解决您的问题,我再为您寻找其他解决方案。

,

?? ?:

您好,我已经验证过这两点没有问题,请问还有可能是哪方面的原因导致的

,

?? ?:

当调试到RF_runCmd()后编译器就会报错强制退出调试模式

,

Yolande Wang:

好的,请问您的项目是基于哪个例程?

我将您的问题升级到 E2E 论坛询问一下。

,

?? ?:

我使用的TI-RTOS,参考的rfPacketTx和rfPacketRx

,

?? ?:

我感觉这个是概率性的问题,因为我有一块板子能正常工作,其他的都是这种情况(硬件和程序都一样的)

,

Yolande Wang:

?? ? 说:我感觉这个是概率性的问题,因为我有一块板子能正常工作,其他的都是这种情况(硬件和程序都一样的)

这样看下来像是板子的原因。

正常的板子和其他不正常的板子有什么不一样吗?

,

?? ?:

板子我也确认过了都是一模一样的,程序也一样

,

Yolande Wang:

好的,我已跟进问题,有进展立即回复您。

,

Yolande Wang:

您好,

以下是E2E的回复:

这是定制板还是在 CC1310 开发板上观察到的?

您是否能在 CC1310 开发板上重现此问题。这可以让我们知道这是主板问题还是软件错误。

,

?? ?:

我们自己的板子,手工焊接对射频部分影响大吗,今天我用机器贴了一片目前没有发现重启的情况,之前手工焊接的几块板子有一块工作是正常的,其他的都是重启的问题。

,

Yolande Wang:

具体情况具体分析,焊接质量肯定是没有贴片的稳定。手焊得好对射频没有什么影响的。

根据您的叙述,问题可能出在焊接,检查是否有虚焊之类的,用万用表测一下有问题的板子看看是否都是连通的。

,

?? ?:

您好,刚才忽然发现那个贴的板子还是会重启,奇怪了,应该不是焊接的问题

,

?? ?:

您好,可以给您发下PCB布局图给看下嘛,是这样的,我这个板子是需要贴到我们主板上使用的(类似于串口透传模块),板子我引出的IPEX座,当我不连接外部天线以及连接外部天线都会有重启的情况发生,射频部分我是参考官方433M部分设计的,我在软件里配置的工作频带是431-527之间的,我感觉像是干扰导致的,项目马上要量产了,帮忙给看下谢谢!!

,

?? ?:

,

Yolande Wang:

您可以尝试在开发板运行此程序吗?

是否可以出于这个确切原因在开发板上重现该问题。如果它可以在开发板上重现,则表明存在软件问题。如果相同的软件在开发板上正常工作,则问题更有可能来自主板本身。

重置可能是由于电源/重置输入上焊接不良造成的。 

,

?? ?:

我手头暂时没有开发板,我是通过参考设计自己做的板子,另外,早上我测试发现之前手工焊的正常工作的那块板子,在某个频段工作正常,但是我切换工作频段后也是在接收到数据后发送的时候重启

,

Yolande Wang:

?? ? 说:射频部分我是参考官方433M部分设计的

稍等我让 E2E 工程师帮您看看 PCB 的原理图。

,

?? ?:

您好,给看过了吗,有问题吗,已经卡好几天了,找不到原因

,

Yolande Wang:

您好,

我会向我们的硬件团队寻求帮助,但我也想知道调试器在退出调试模式之前报告的错误是什么。 

,

Yolande Wang:

?? ? 说:当调试到RF_runCmd()后编译器就会报错强制退出调试模式

这里报错信息是什么?

,

?? ?:

这次早上又发现调用TxAdv命令也会导致重启

,

?? ?:

   这些是报错信息,帮忙看下

,

Yolande Wang:

正在跟进问题,稍等一下。

,

?? ?:

好的,那会我调试发100ms的TxAdv调试正常,但是更改为1S的前导就开始重启。像这种情况如何获取卡死原因呢,runCmd()卡死的话RF回调也不执行

,

Yolande Wang:

可能因为前导时间过长导致资源消耗过多或硬件相关。

要解决这个问题,您可以尝试缩短前导时间,检查设备的资源使用情况确保没有超过限制。

,

?? ?:

我现在射频部分没有做50欧阻抗匹配,如果射频参数较差的情况会引起芯片重启吗,因为我现在调整下模块方向有时候确实也可以发1S的前导包,是不是干扰导致的,我的原理图和PCB布局有问题吗,都是按照参考设计来的

,

Yolande Wang:

?? ? 说:我现在射频部分没有做50欧阻抗匹配,如果射频参数较差的情况会引起芯片重启吗

会的,等硬件工程帮您看下,暂时还没有回复我。

,

?? ?:

我抓了下重启原因,显示 RSTSRC_CLK_LOSS

,

Yolande Wang:

复位源是RSTSRC_CLK_LOSS,表明您的 SCLK_LF 或 SCLK_HF 时钟源已停止。您使用什么作为 SCLK_LF 源?外部 32K XOSC 还是内部 LF RCOSC?还是SCLK_HF源?

完整reset source可以看下这个链接:https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/2_20_00_06/exports/tirtos_full_2_20_00_06/products/cc26xxware_2_24_02_17202/doc/driverlib/group__sysctrl__api.html

,

?? ?:

 外部32.768K晶体,这些都是默认的没动过

,

Yolande Wang:

时钟丢失导致的,可能是由于时钟源不稳定。

原因可能是电源不稳定或者外部干扰。

确保射频线路和时钟线路有足够的隔离,防止射频信号对时钟有干扰。

,

?? ?:

好的,这点我会注意,另外您请工程师帮我看了吗,原理图和布局有问题吗

,

Yolande Wang:

英文论坛那边回复会有时差,辛苦您等候一下。

,

Yolande Wang:

以下是E2E的回复:

我已经通知硬件工程师了。但要确定的是,这个问题只发生在手工焊接样品上的说法仍然正确吗? 

?? ? 说:用机器贴了一片目前没有发现重启的情况,之前手工焊接的几块板子有一块工作是正常的,

如果机器焊接样品上没有重现该问题,我认为这不是软件错误,而是硬件问题。我会让硬件工程师在这里回复。

另外,您可以点击此链接直接查看:https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1313391/cc1310-cc1310-is-set-to-long-receiving-mode-brepeatok-and-brepeatnok-are-both-1-after-the-rf-receives-the-data-the-output-through-the-serial-port-is-normal-however-after-the-serial-port-receives-the-data-the-rf-switches-and-s/4999068#4999068

,

?? ?:

您好,机器贴的也会发生,但是我确实有一块手工焊接的一样的程序运行良好(但是切换频段后也会有重启的情况,在某一频段工作正常),所以我觉得应该是硬件有些问题,麻烦您让工程师帮忙看下,如果需要其他的资料和我说

,

Yolande Wang:

好的,有进展立即回复您。

,

?? ?:

您好,我看到论坛上外国工程师回复需要进行硬件审查,我们去年8月份就发了一份另一个设备的硬件审查,至今仍没有回复!

,

Yolande Wang:

您好,

之前发布的硬件审查如果没有回复,可以联系我们帮您跟进。

目前这个设备,E2E 工程师的建议是:

请您使用以下方式提交其设计以供审核: 低于 1 GHz 设计审核提交:https://www.ti.com/tool/SIMPLELINK-SUB1GHZ-DESIGN-REVIEWS 

我们需要更多的信息,而不仅仅是设计的顶层,并且此方法是保密的 – 请您在请求表(或提交电子邮件)中链接到此线程,以便我知道它与此问题相关。

 

,

Yolande Wang:

?? ? 说:您好,机器贴的也会发生,但是我确实有一块手工焊接的一样的程序运行良好(但是切换频段后也会有重启的情况,在某一频段工作正常),所以我觉得应该是硬件有些问题,麻烦您让工程师帮忙看下,如果需要其他的资料和我说

您好,

硬件工程师看过了您发的 PCB 布局图,单单从图片没看出问题。

建议提交硬件审查,但考虑到您着急量产,时间上来不及。

不过您这边更多的是还得检查硬件,如有硬件的技术支持需要,可以联系我们的现场应用工程师。

,

?? ?:

您好,请问如何联系,确实比较着急

,

Yolande Wang:

您好,

您可以联系一下我们目前唯一的代理商Arrow,E2E论坛仅提供线上技术支持。

感谢理解!

,

?? ?:

我问了一下Arrow,他们说只卖元器件,没有技术支持?

,

?? ?:

如果我现在提交硬件审查,多久能得到回复啊

,

Yolande Wang:

您好,

这个时间我们也不确定多久。

不过,您已经发了硬件审核需求但是还没有得到回复,我可以帮您询问跟进。

,

?? ?:

那之前的能帮我跟进一下吗,这个我也抓紧提交一个硬件审核

,

Yolande Wang:

之前的提交您需要联系当时给您技术支持的工程师或者给收件人发邮件。

目前这个我可以帮您跟进。

,

?? ?:

过年好! 年前由于工作原因,这个项目由于重启原因暂停了,现在又恢复了,但还是比较着急,所以我明天会提交下硬件审查,麻烦您帮忙给跟进一下,谢谢!

,

?? ?:

 已经提交了,希望这两天您能给跟进下,感谢!

赞(0)
未经允许不得转载:TI中文支持网 » CC1310: 设置CC1310为长接收模式(bRepeatOk以及bRepeatNok都为1),在RF接收到数据后通过串口输出正常,但是串口收到数据后RF切换发送之后异常(调用RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropTx, RF_PriorityNormal, NULL, 0);导致设备重启)。
分享到: 更多 (0)