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.
https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1160456/cc1352p-how-to-reset-rf-core-separately
大家好、
以下是客户的请求：
在 CC1352P 的正常使用期间、射频内核偶尔会崩溃。 如果 单独复位射频内核、则可能节省 大量额外开支、而不 是复位整个器件。 是否有办法单独复位射频内核？
时间
您可以帮助检查此案例吗？ 谢谢。
此致、
Nick
您好、Nick、 以下答案是否适用于他们？ https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1160174/cc1352p7-ability-to-reset-the-rf-cpu-from-the-application-processor
Arthur
尊敬的 Arthur：
客户观察到、当程序执行特定的 Easylink_receive()时(超时时间设置为40ms)、它将始终阻止程序内部并且无法退出。 在这方面 、它们确定射频内核已死、 并希望通过一种方法重置射频内核来解决此问题。
他们认为，在 state.semSync 分析了 Easylink_receive()和 RF_pendCmd()的源代码之后，程序可能会在 Easylink_receive()和 RF_pendCmd()的 Easylink_receive()中被阻止。
此时，如果在其他任务中调用了 RF_Close()和 RF_open()，则它们认为它无效，因为信标被占用。
还有其他解决方案吗？
您好！ 此时、我不认为是 RF 内核崩溃、但最有可能是 EasyLink 出现了问题。 他们能否在代码被阻止的位置共享代码的一部分？ 此致、 Arthur
