1：无法打开下载文件进行程序下载。
这是早些时候刚拿到开发板遇到的第一个问题。当时还一头雾水，挠破头皮时才发现有个选项没选对，link选项里面应该选output输出文件而不是debug调试文件。
2：串口接收相邻字节间的时间间隔
由于采用的轮询串口接收中断标志的方式来接收存储串口数据，所以需要判断一个连续的数据流什么时候结束。经反复实验，得出一个经验数值：以9600bps为例，连续发送的字节间间隔时间小于2.8ms，即在判断一个数据是否结束时，应至少等待2.8ms看是否接收到新的一个字节，若接收到则此数据流是连续的，还没结束；若等待2.8ms仍没数据接收到，则可以判断此数据流已经结束。用C写的代码，对中断标志的查询大约循环400次≈2.8ms
3：串口有可能接收到假数据
当对方没有数据向2430的串口发送时，串口不能对中断标志进行无限循环的等待，必须设置一个最大等待次数，超过门限就退出循环。但是实际实验时发现往往设置了门限却退不出循环，串口轮询接收函数死在那了，这个问题困扰了好久，最后才偶然的发现即使串口悬空，对方没有任何数据发向2430的串口，但串口仍然有可能收到一些全是0x00或是全0xFF或着杂乱无章的数据。于是前面的问题有答案了：串口接收函数即使设置了最大循环等待次数，但接收函数无法退出的原因并不在此，而是接收到了连续不断的假数据！！由于一直处于接收状态，而且数据流又没断，所以串口一直在接收直到内存溢出，直到程序跑飞，也不可能超过等待次数返回。所以解决办法：写串口中断轮询接收函数必须再加上一个输入参数，即最大允许接收字节数。
4：PC上位机的串口接收程序和cc2430下位机的串口发送配合问题
底下的2430源源不断在向PC的RS232口发数据，PC上用VC写的定时器触发不停的查询串口接收缓冲区数据，但明显的PC上收到数据没2430发的那么多。显然PC在接收串口的过程中随机地丢掉了几个数据包，使得数据更新速度很慢。经过仔细分析，原因是PC上定时器触发的时间间隔和串口接收耗时的配合出现了问题，以9600bps的速率为例，发送100字节，需时至少93ms，也就是说PC从收到第一个字节到收到最后一个字节中间持续时间至少得93ms，如果这中间发生了定时器触发读出缓冲区数据，则肯定数据是不完整的，会发生数据错误产生丢包现象。解决办法：尽量提高串口传输速率，尽量延长PC定时器触发间隔。例如：采用57.6kbps的速率，传送100字节需时约16ms，而定时器触发间隔设置为100ms，这样在数据接收期间发生定时器触发的几率就大大下降了，丢包率也就小多了。
5：RF的单次发送最大字节数
一开始没认真阅读手册，一上来就传几百个字节，结果往往只有前面的字节收到了，后面的数据全丢了。仔细研究手册过后才知道，CC2430的RF缓冲FIFO只有128字节，除开最后两个字节的RSSI和LQI，实际最长载荷只有126字节，如果采用spp简单传输协议，再除开前面4个字节的开销(包长、目的地址、源地址、标志)，实际净载荷只有122字节。超过122字节的数据只有自己拆开分多次传输。
6：radioSend()函数的DO_ACK选项
Chipcom提供的CUL库里面的这个radioSend()函数是spp协议的简单发送函数，里面有DO_ACK选项，以提供对方收到后进行一次简短应答来确认是否发送成功。但是经过多次实验，若使用DO_ACK选项，则函数无法返回，会死在里面。所以最好的调用方法就是使用DO_NOT_ACK