cc2500 module with possible TX/RX problems

Soumitra,

Have you followed the power up procedure of CC2500 as per the datasheet. There is a bunch of registers that needs to be downloaded too.

Regards,
/TA 

Hi TA

Thank you for the reply and yes i did, in fact this is from a working example that was written for sending ADC values to a receiver. 

Just in case these are the register settings used :

const cRFSettings : RF_SETTINGS = (
0x0A, // FSCTRL1 Frequency synthesizer control.
0x00, // FSCTRL0 Frequency synthesizer control.
0x5D, // FREQ2 Frequency control word, high byte.
0x93, // FREQ1 Frequency control word, middle byte.
0xB1, // FREQ0 Frequency control word, low byte.
0x2D, // MDMCFG4 Modem configuration.
0x3B, // MDMCFG3 Modem configuration.
0x73, // MDMCFG2 Modem configuration.
0x22, // MDMCFG1 Modem configuration.
0xF8, // MDMCFG0 Modem configuration.
0x00, // CHANNR Channel number.
0x01, // DEVIATN Modem deviation setting (when FSK modulation is enabled).
0xB6, // FREND1 Front end RX configuration.
0x10, // FREND0 Front end TX configuration.
0x18, // MCSM0 Main Radio Control State Machine configuration.
0x1D, // FOCCFG Frequency Offset Compensation Configuration.
0x1C, // BSCFG Bit synchronization Configuration.
0xC7, // AGCCTRL2 AGC control.
0x00, // AGCCTRL1 AGC control.
0xB0, // AGCCTRL0 AGC control.
0xEA, // FSCAL3 Frequency synthesizer calibration.
0x0A, // FSCAL2 Frequency synthesizer calibration.
0x00, // FSCAL1 Frequency synthesizer calibration.
0x11, // FSCAL0 Frequency synthesizer calibration.
0x59, // FSTEST Frequency synthesizer calibration.
0x88, // TEST2 Various test settings.
0x31, // TEST1 Various test settings.
0x0B, // TEST0 Various test settings.
0x07, // FIFOTHR RXFIFO and TXFIFO thresholds.
0x29, // IOCFG2 GDO2 output pin configuration.
0x06, // IOCFG0D GDO0 output pin configuration.
0x06, // PKTCTRL1 Packet automation control. //04
0x05, // PKTCTRL0 Packet automation control.
0x30, // ADDR Device address.
0xFF // PKTLEN Packet length.
);

Regards

Soumitra

What im getting from the GDO0 pin is 0x01 (RX FIFO: Asserts when RX FIFO is filled at or above the RX FIFO threshold or the end of packet is reached. De-asserts when the RX FIFO is empty.)

followed by 0x00 

Also, the packetLength in the routine = 1, and I am transmitting a word value split into 2 bytes ... so i wonder if the packets received are correct or the modules are working fine themselves.

BOOL halRfReceivePacket(BYTE *rxBuffer, UINT8 *length) {
    BYTE status[2];
    UINT8 packetLength;

    halSpiStrobe(CCxxx0_SRX);
    while (!GDO0_PIN);
    while (GDO0_PIN);
    if ((halSpiReadStatus(CCxxx0_RXBYTES) & BYTES_IN_RXFIFO)) {

        // Read length byte
        packetLength = halSpiReadReg(CCxxx0_RXFIFO);

Thanks and regards

Soumitra, 

This indicates that you have not yet successfully communicated with the CC2500. The first step you need to complete is to be able to write and read to a register. Try various values except 0 and 255. Use an oscilloscope to debug the lines as you progress.

Regards,
/TA 

Thank you TA

That was a great diagnosis.... it seems one of the SPI channels in my mcu is not working or initialized properly yet, due to a bad solder joint. Anyways, the SPI is working now and ive checked the data lines with the oscilloscope. But i still dont get the modules working.

Is there a way to check  if the transmitter is working and transmitting the correct data ?

Thank you once again

Regards

Soumitra

Soumitra, 

After you program all the registers, you now need to fill the FIFO with transmit data and issue "STX" command.

As a debugging trick, I typically poll the MARC_STATE registers as fast as the MCU will allow me to and store each result in an array for later analysis. Specifically what I do is read the MARC_STATE register 1000 times, then look at them to make sure the radio goes thru all the different states specified in the datasheet.

If the state of the radio ends up in a weird state, you can use this information to figure out what your next step is.

Regards,
/TA 

Thank you TA

Just to confirm, the STX command is sent after a burst write within the HalRfSendPacket method. This is the same code as in the TI examples archive.

My mcu can be clocked upto 48mhz ... so I followed your advice and checked the MARC_STATE at different intervals in the code flow.

function GetMarcState: Byte;
begin
  Result := HalSpiReadStatus(CCxxx0_MARCSTATE);
end;

I get nothing from the status register before the 

HalRfSendPacket(@txBuffer, 3);     // send 3 bytes

But get a 0x00 (sleep) after sending the packets.

I also tried the following method within the lib but this does not seem to return any value as in the main execution block of the program hangs if i enable this debug method.

var RF_STATUS: array[255] of Byte;
var RF_C: Byte;

procedure GetMStatus;
begin
  if RF_C < 255 then
  begin
    RF_STATUS[RF_C] := RfSpiReadStatus(CCxxx0_MARCSTATE);
    Inc(RF_C);
  end;
end;

procedure RfSendPacket(txBuffer : ^byte; size : byte);
begin
  temp := RfSpiReadReg(CCxxx0_MCSM0);
  RfSpiWriteBurstReg(CCxxx0_TXFIFO, txBuffer, size);
  RfSpiStrobe(CCxxx0_STX);
{$IFDEF DEBUG}
  GetMStatus;
{$ENDIF}
  while(RF_GD0 = 0) do nop;
  while(RF_GDO = 1) do nop;
end;

Im not sure what else I can do at this point. Any help ?

Thank you and regards

Soumitra