PSoC4操作CC1101遇到的问题

只看该作者 · 2015-4-23 23:41

最近在做一个项目，要用到CC1101，遇到了好多问题，在这里请教下大家，另外给大家分享些经验。

只看该作者 · 2015-4-23 23:44

void writeRFSettings(unsigned char channel)
{

// Write register settings
TI_CC_SPIWriteReg(TI_CCxxx0_IOCFG2, 0x0B); // GDO2 output pin config.
TI_CC_SPIWriteReg(TI_CCxxx0_IOCFG0, 0x06); // GDO0 output pin config.
TI_CC_SPIWriteReg(TI_CCxxx0_FIFOTHR,  0x0F); // .
TI_CC_SPIWriteReg(TI_CCxxx0_PKTLEN, 0xFF); // Packet length.
TI_CC_SPIWriteReg(TI_CCxxx0_PKTCTRL1, 0x04); // Packet automation control.有两个附加字节，一个rssi lqi
TI_CC_SPIWriteReg(TI_CCxxx0_PKTCTRL0, 0x05); // Packet automation control.,CRC_EN VARIABLE LENGTH
TI_CC_SPIWriteReg(TI_CCxxx0_ADDR,    0x01); // Device address.
TI_CC_SPIWriteReg(TI_CCxxx0_CHANNR, channel); // Channel number.//这里换通道，岔开一个 2*（柜号-1）
TI_CC_SPIWriteReg(TI_CCxxx0_FSCTRL1,  0x06); // Freq synthesizer control.
TI_CC_SPIWriteReg(TI_CCxxx0_FSCTRL0,  0x00); // Freq synthesizer control.
TI_CC_SPIWriteReg(TI_CCxxx0_FREQ2, 0x10); // Freq control word, high byte
TI_CC_SPIWriteReg(TI_CCxxx0_FREQ1, 0xA7); // Freq control word, mid byte.
TI_CC_SPIWriteReg(TI_CCxxx0_FREQ0, 0x62); // Freq control word, low byte.
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG4,  0xF8); // Modem configuration.    //F5,83通信波特率为1.2K,F8,93通信波特率为10K,
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG3,  0x93); // Modem configuration.
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG2,  0x03); // Modem configuration.  //主机用0x03,更好的灵敏度。原来是0x83  ,200
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG1,  0x22); // Modem configuration.
TI_CC_SPIWriteReg(TI_CCxxx0_MDMCFG0,  0xF8); // Modem configuration.
TI_CC_SPIWriteReg(TI_CCxxx0_DEVIATN,  0x15); // Modem dev (when FSK mod en)
TI_CC_SPIWriteReg(TI_CCxxx0_MCSM1 , 0x3F); //MainRadio Cntrl State Machine0x3F
TI_CC_SPIWriteReg(TI_CCxxx0_MCSM0 , 0x18); //MainRadio Cntrl State Machine
TI_CC_SPIWriteReg(TI_CCxxx0_FOCCFG, 0x16); // Freq Offset Compens. Config
TI_CC_SPIWriteReg(TI_CCxxx0_BSCFG, 0x6C); //  Bit synchronization config.
TI_CC_SPIWriteReg(TI_CCxxx0_AGCCTRL2, 0x03); // AGC control.
TI_CC_SPIWriteReg(TI_CCxxx0_AGCCTRL1, 0x40); // AGC control.
TI_CC_SPIWriteReg(TI_CCxxx0_AGCCTRL0, 0x91); // AGC control.
TI_CC_SPIWriteReg(TI_CCxxx0_FREND1, 0x56); // Front end RX configuration.
TI_CC_SPIWriteReg(TI_CCxxx0_FREND0, 0x10); // Front end RX configuration.
TI_CC_SPIWriteReg(TI_CCxxx0_FSCAL3, 0xE9); // Frequency synthesizer cal.
TI_CC_SPIWriteReg(TI_CCxxx0_FSCAL2, 0x2A); // Frequency synthesizer cal.
TI_CC_SPIWriteReg(TI_CCxxx0_FSCAL1, 0x00); // Frequency synthesizer cal.
TI_CC_SPIWriteReg(TI_CCxxx0_FSCAL0, 0x1F); // Frequency synthesizer cal.
TI_CC_SPIWriteReg(TI_CCxxx0_FSTEST, 0x59); // Frequency synthesizer cal.
TI_CC_SPIWriteReg(TI_CCxxx0_TEST2, 0x81); // Various test settings.
TI_CC_SPIWriteReg(TI_CCxxx0_TEST1, 0x35); // Various test settings.
TI_CC_SPIWriteReg(TI_CCxxx0_TEST0, 0x09); // Various test settings.
}

只看该作者 · 2015-4-23 23:48

//-----------------------------------------------------------------------------
//  char RFReceivePacket(char *rxBuffer, char *length)
//
//  DESCRIPTION:
//  Receives a packet of variable length (first byte in the packet must be the
//  length byte).  The packet length should not exceed the RXFIFO size.  To use
//  this function, APPEND_STATUS in the PKTCTRL1 register must be enabled.  It
//  is assumed that the function is called after it is known that a packet has
//  been received; for example, in response to GDO0 going low when it is
//  configured to output packet reception status.
//
//  The RXBYTES register is first read to ensure there are bytes in the FIFO.
//  This is done because the GDO signal will go high even if the FIFO is flushed
//  due to address filtering, CRC filtering, or packet length filtering.
//
//  ARGUMENTS:
//    char *rxBuffer
//       Pointer to the buffer where the incoming data should be stored
//    char *length
//       Pointer to a variable containing the size of the buffer where the
//       incoming data should be stored. After this function returns, that
//       variable holds the packet length.
//
//  RETURN VALUE:
//    char
//       0x80:  CRC OK
//       0x00:  CRC NOT OK (or no pkt was put in the RXFIFO due to filtering)
//-----------------------------------------------------------------------------
char RFReceivePacket(char *rxBuffer, char *length)
{
  char status[2];
  char pktLen;

  if ((TI_CC_SPIReadStatus(TI_CCxxx0_RXBYTES) & TI_CCxxx0_NUM_RXBYTES))
  {
pktLen = TI_CC_SPIReadReg(TI_CCxxx0_RXFIFO); // Read length byte

if (pktLen <= *length)                // If pktLen size <= rxBuffer
{
   TI_CC_SPIReadBurstReg(TI_CCxxx0_RXFIFO, rxBuffer, pktLen); // Pull data
   *length = pktLen;                   // Return the actual size
   TI_CC_SPIReadBurstReg(TI_CCxxx0_RXFIFO, status, 2);
                                          // Read appended status bytes
   return (char)(status[TI_CCxxx0_LQI_RX]&TI_CCxxx0_CRC_OK);
}                                     // Return CRC_OK bit
else
{
   *length = pktLen;                   // Return the large size
   TI_CC_SPIStrobe(TI_CCxxx0_SFRX);    // Flush RXFIFO
   return 0;                            // Error
}
  }
  else
   return 0;                            // Error
}

只看该作者 · 2015-4-23 23:50

产品描述
CC1101是低成本的1GHz以下的无线收发器，为极低功耗的无线应用而设计。电路主要设
计为ISM(工业、科学和医疗)和SRD(短距离设备)，频段在315、433、868和915，但是可
以很容易的编程，使之工作在其他频率，在300-348MHz，387-464  MHz 和  779-928  MHz
频段。
CC1101是CC1100 RF收发器改良以及代码一致的版本。CC1101的主要改进如下：
l  改良的伪应答
l  更好的关闭相位噪声，因而改善相邻信道功耗（ACP）的性能
l  更高的输入饱和级别
l  改善输出功率斜面
l  扩大工作频段：
CC1100: 400-464 MHz and 800-928MHz
CC1101: 387-464 MHz and 779-928MHz

只看该作者 · 2015-4-23 23:50

当在SPI接口上发送头字节，数据字节或者命令选通（command  strobe）时，CC1101
在SO引脚上发送芯片状态字节。状态字节包含对MCU有用的关键状态信号。第1位，S7，
为CHIP_RDYn信号，在SCLK的第一个上升沿之前，该信号必须变为低电平。CHIP_RDYn表
示晶振已经开始工作。
  第6、5、4位组成（STATE）状态值，该值反映芯片的状态。在空闲（IDLE）状态，
XOSC和数字核的电源被打开，但是其他模块全部掉电。频率和信道配置只能在芯片处于该
状态时被更新。当芯片处于接收模式时，接收（RX）状态被激活。同样，当芯片处于发送
模式时，发送（TX）状态被激活。
  状态字节的最后4位（3：0）包含FIFO_BYTES_AVAILABLE。在读操作中（头字节的
R/W位置1），FIFO_BYTES_AVAILABLE包含从RX FIFO可读到的数据字节数。在写操作中
（头字节的R/W位置0），FIFO_BYTES_AVAILABLE 包含可写入到TX FIFO中的字节数。
当FIFO_BYTES_AVAILABLE=15，15个或者更多字节是可读的/空闲的。
表20为状态字节概要。

只看该作者 · 2015-4-25 07:28

CC1101的接收有些问题，好多人都遇到过类似的问题

只看该作者 · 2015-4-25 07:30

我也碰到过这个问题！可能在你接收完成了，还没有来的急判断下一个接受，下一个接接收已经完成了，所以退出接收状态了，定时的将CC1101转入接收状态就不会出现所谓的死机了！

只看该作者 · 2015-4-25 07:30

要软件再发进入SLIDE,然后再进入接收才行

只看该作者 · 2015-4-25 07:31

cc1101 晶振要定时的校准，特别是长时间的接收。

只看该作者 · 2015-4-25 07:34

问题现象一、在确认数据端正常工作且发送数据情况下，使用CC1101进行数据接收，过一段时间之后CC1101接收不到数据了。

原因及解决方法：这个问题比较诡异，应该是CC1101的芯片设计问题：锁相环漂移，由此造成的频率合成器的接收频率、带宽位置变化。解决该问题的方法也很简单，定期进行频率校准。既可以使用Strobe命令进行手动校准:SCAL，亦可在MCSM0.FS_AUTOCAL设置为1，然后在程序中定期的执行:SIDLE加SRX或SRT命令，重新进行频率校准。

只看该作者 · 2015-4-25 07:34

问题现象二、配置GDO2管脚为0x07,即当CC1101接收到数据并CRC校验正确之后，管脚Assert,但实际调试过程中，经常出现，GDO2管脚不正常电平跳变，提示有数据接收并校验正确，但此时去读RXBYTES(0x3B)这个状态寄存器时，读出的数值为0是无数据的，而直接读取RX FIFO又有数据（之前已经用SFRX命令冲掉了RX FIFO数据的）。

原因及解决方法：该方法目前不知道是不是硬件电路设计不够稳定的原因，我的解决方法是，检测到GDO2管脚电平Assert后，首先延时1000us（至少500us,实测少于该数值，读读取的RXBYTES寄存器数值不稳定不正确），然后读取RXBYTES寄存器，如果数值不为0，再读取RX FIFO中的数据。

只看该作者 · 2015-4-25 07:35

问题现象三、调试的时候，配置GDO0为0x06。进行数据发送的时候，首先将长度数据写入TX FIFO，然后Burst方式连续写入要发送的数据，之后再将CC1101转换到TX模式。根据手册上说的，GDO0会首先Assert表示已经发送/收到了同步字，然后管脚电平De-Assert指示数据封包已经发送完毕。所以采用while(GDO2_IN);的方式进行判断，但却始终卡在这里死循环。就此问题，我在网上看到很多网友也遇到了类似的疑问，这里正好也说一下；

原因及解决方法：在CC1101 User Guider的第33页有这样一句话：The burst access method expects one header byte and then consecutive data bytes until terminating the access by setting CSn high。问题大多都出在Burst读写后，没有拉高CSN管脚电平，而是又直接进行其他命令操作。解决方法即Burst方式读写之后，立即将CC1101的CSN管脚电平上拉，等待至少10us,然后再进行STX等操作，这样芯片就能正常地将数据发送出去了。