TI中文支持网Part Number:CC1310
我们使用一片配备了4*4规格CC1310的电路板作为TX端进行数据传输（high speed mode，包间隔10ms），外围电路均使用TI参考设计。代码逻辑为TX端发送数据后，RX端接收并回传包，TX端在接收到回包后进行下一包数据传输。
问题现象：在TX板上运行程序，三分钟左右后会卡死在StateMachine_exec中，具体停留在了IntMasterDisable
对比测试：
1.单独发射载波例程，可持续运行；
2.取消接收回包操作，仅连续发送数据，仍会卡死；
3.将包间隔增加至1s，可持续运行，不会卡死
问题分析：
当程序卡死时，通过CCSdebug分析查看寄存器发现R14值为0xfffffff9，MSP寄存器值为0x20004f78，且CFSR 寄存器中出现了 IMPRECIESERR 标志。通过观察栈区地址0x20004f78处的返回地址LR为函数IntMasterDisable，推测程序发生了不精确的数据访问冲突导致中断去使能时识别到了异常未正确处理，导致系统lockup。通过配置CPU_SCS_O_ACTLR寄存器禁止写入，卡死时R14值为0xfffffff9，MSP寄存器值为0x20004f78，观察CFSR寄存器出现PRECIESERR，此时BAFR为0x00000001,通过观察栈区此地址并未发现任何异常。
我们在传输数据状态机的开始与结束分别增加1us的延时后，程序卡死情况消失。问题原因是否为内部某些窗口时间冲突？为在后续产品中彻底根除此问题，请告诉我们该问题的具体原因。
Galaxy Yue：
你好，
ancient frog 说：问题原因是否为内部某些窗口时间冲突？
感觉这个可能性是最大的，因为你添加延时之后，程序不再卡死。并且是在高速模式下，时间管理不当会出现同时访问共享资源，就会卡。
还有可能是中断处理存在逻辑错误，但是延时之后能正常跑程序，应该可能性不大。
软件死锁，资源争用，就是软件中的同步机制没有处理好。
,
ancient frog：
之后测试中发现，在图片发送状态机末尾加上usleep(1),休眠1us，程序正常运行，如果用for循环或CPUdelay API进行1us延时仍然会卡死。
,
Galaxy Yue：
usleep利用了系统底层的定时器或调度器来提供精确的延时。
从这个现象来看，问题可能与时间精度和稳定性有关。在高速传输过程中，系统的时序要求非常严格，可能需要非常精确和稳定的延时操作来确保各个部分之间的协调运行。
只有传输图片这样还是其他数据也会？
,
ancient frog：
使用图片发送状态机传输其他数据也存在卡死现象。
目前我们测试显示：使用<1>状态机末尾增加usleep（尝试过1us至1ms）与<2>在图片发送状态机末尾加上串口打印，串口设置为block阻塞模式两种方法均可解决卡死问题；
但若串口设置为callback模式则会卡死。
所以usleep是否与block阻塞模式存在某种类似特性，在延时的同时对一些资源或数据进行操作？
,
Galaxy Yue：
当调用usleep()函数时，程序会暂停执行一段时间，这段时间内程序会等待而不进行其他操作。这就意味着在延时的同时，程序可能无法进行其他资源或数据的操作，因为程序的执行被暂时挂起了。
当使用block阻塞模式时，程序也会在某些操作上被阻塞，直到特定的条件满足或者事件完成。在这种情况下，程序也无法进行其他操作，因为它被阻塞在某个操作上。
相比之下，callback模式通常是异步非阻塞的，它不会等待某些事件的发生而是通过回调函数来处理事件。这意味着程序将继续执行而不等待事件完成，因此在callback模式下，可能需要等待较长时间才能处理完所有的事件，从而导致卡死现象。
因此，usleep()函数和block阻塞模式都会导致程序在一定时间内无法进行其他操作。
