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.

CC1200: Can't read registers after putting into RX (or TX) mode

Part Number: CC1200

I have a set of register values that have been taken from a previous design (that used values generated from SmartRF Studio).

I can read and write registers fine over SPI after a reset, checking CHIP_RDYn etc. However when I issue an SRX cmd to enter RX mode, every time I try and read a register, the contents always come back as 0xx00. I'll paste some debug output below, but it's not very exciting.

I wasn't actually needing to read a register at this stage but I wanted to read the MARCSTATE register just for fun to check it has gone into RX mode (or some settling state while it calibrated). At some point in the future I will want to read the RSSI when I am processing a receive packet, but that's for another day.

There was a note in section 3.1.2 of the User's Guide that implies you shouldn't really fiddle with the registers in any state other than IDLE, but it doesn't say you can't read any? 

Seeing as the values are 0x00 I wouldn't trust trying to read the STATUS register because  it would normally be 0x00 if in IDLE mode anyway, so I wouldn't be able to tell the difference

RF Transceiver (CC1200) is present.
RF Transceiver is ready.
AGC_CFG0_REG_ADDR = 0x87
AGC_CFG1_REG_ADDR = 0x51
AGC_CS_THR_REG_ADDR = 0xec
CHAN_BW_REG_ADDR = 0x0b
FIFO_CFG_REG_ADDR = 0x00
FS_CAL0_REG_ADDR = 0x0e
FS_CAL1_REG_ADDR = 0x40
FS_CFG_REG_ADDR = 0x14
FS_DIG0_REG_ADDR = 0xaf
FS_DIG1_REG_ADDR = 0x07
FS_DIVTWO_REG_ADDR = 0x03
FS_DSM0_REG_ADDR = 0x33
FS_DVC0_REG_ADDR = 0x17
FS_PFD_REG_ADDR = 0x00
FS_REG_DIV_CML_REG_ADDR = 0x1c
FS_SPARE_REG_ADDR = 0xac
FS_VCO0_REG_ADDR = 0xb5
IF_ADC0_REG_ADDR = 0x10
IF_ADC1_REG_ADDR = 0xee
IQIC_REG_ADDR = 0xcb
MDMCFG2_REG_ADDR = 0x08
MODCFG_DEV_E_REG_ADDR = 0x03
PA_CFG1_REG_ADDR = 0x6d
PKT_CFG0_REG_ADDR = 0x20
PKT_CFG1_REG_ADDR = 0x00
PKT_CFG2_REG_ADDR = 0x03
PKT_LEN_REG_ADDR = 0xff
PREAMBLE_CFG0_REG_ADDR = 0x8a
PREAMBLE_CFG1_REG_ADDR = 0x00
SERIAL_STATUS_REG_ADDR = 0x08
SYMBOL_RATE0_REG_ADDR = 0x4e
SYMBOL_RATE1_REG_ADDR = 0x62
SYMBOL_RATE2_REG_ADDR = 0x70
XOSC1_REG_ADDR = 0x03
XOSC5_REG_ADDR = 0x0e
write to IOCFG3_REG_ADDR returned 0.
IOCFG3_REG_ADDR = 0x11
write to IOCFG2_REG_ADDR returned 0.
IOCFG2_REG_ADDR = 0x09
Entering RX mode...
MARCSTATE_REG_ADDR = 0x00
IOCFG3_REG_ADDR = 0x00, status = 0
IOCFG2_REG_ADDR = 0x00, status = 0
IOCFG1_REG_ADDR = 0x00, status = 0
FREQ0_REG_ADDR = 0x00
FREQ1_REG_ADDR = 0x00
FREQ2_REG_ADDR = 0x00
SYNC_CFG1_REG_ADDR = 0x00
DEVIATION_M_REG_ADDR = 0x00
DCFILT_CFG_REG_ADDR = 0x00
MDMCFG1_REG_ADDR = 0x00
MDMCFG0_REG_ADDR = 0x00
AGC_REF_REG_ADDR = 0x00
AGC_CFG3_REG_ADDR = 0x00
FREQOFF_CFG_REG_ADDR = 0x00
MARCSTATE_REG_ADDR = 0x00

  • Hi Gary,

    I've assigned this thread to someone. They should reply shortly.

    BR,
    Andres

  • It is not a problem to read registers while you are in RX.

    The following code was tested on our TrxEB + CC1200 EM after writing recommended register settings from SmartRF Studio to the device:

    uint8 marcState;
    uint8 test[20];
       
    cc120xSpiReadReg(CC120X_MARCSTATE, &marcState, 1);
      
    cc120xSpiReadReg(CC120X_IOCFG3, test, 10);
        
    trxSpiCmdStrobe(CC120X_SRX);
        
    do{
        cc120xSpiReadReg(CC120X_MARCSTATE, &marcState, 1);
    } while (marcState != 0x6D);
        
    cc120xSpiReadReg(CC120X_IOCFG3, test, 10);
    

    Zooming in, we can see that MARCSTATE reports that the device is in IDLE mode (0x41):

    After that I read the 10 first registers (IOCFG3 – SYNC_CFG0), and then I strobe SRX (0x34)

    After polling MARCSATET for a while, waiting for the device to enter RX (0x6D), I read the same registers over again, and they have the same values as before:

    I recommend that you use a logic analyzer to monitor the lines when communication over SPI to see that everything looks OK.

    Siri

  • Hi. Thanks for that. I did think about looking at the SPI pins, but unfortunately my hardware guys weren't very generous with the test points and the PCB is very small. I shall wait until I am back in the office and can hookup some Kynar properly. I shall report back what I find in case anyone else makes whatever mistake I've made.

    On a positive note I can confirm that the device does what it is supposed to do in RX mode and I am receiving the expected packets. When I switch back to IDLE mode I am able to read registers as expected, so as you suggest, maybe an SPI problem after issuing the SRX strobe.

  • Hi. Sorry for slight delay but I am all up and running now.

    First let me publicly apologize to my hardware chums for saying they didn't give me any testpoints. I should have checked first because they had given me all the testpoints I needed Smiley

    My problem in the end was that I wasn't enabling a 3V3 regulator for the RF transceiver. There must've been enough parasitic power from nearby pins to allow it to limp along and even decode RF packets, but not enough for read registers in RX mode.