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.

CC1120: Trouble with initialization

Part Number: CC1120
Other Parts Discussed in Thread: MSP430FR5994,

I seem to be struggling to get my CC1120 EVM talking with my MSP430FR5994. As of now, this is a barebones project, where the focus is simply to get the radio working, with the existing swrc253e example code. 

Setup:

Board: MSPFR5994 Launchpad

Booster pack: EM Adapter

RF Module: CC1120EM(915Mhz)

Software Pack: swrc253e

According to the Booster/Launchpad docs, my pinout should look like this:

Launchpad                        Signal           CC1120_RF_EM

VDD                              VDD              2:7/9
P1.2                             GPIOB(2)         1:12
P6:1                             GPIO(TX)         1:9
P6:0                             GPIO(RX)         1:7
P5:2                             SPI CLK          1:16
P7:0                             GPIO5            2:19
GND                              GND              P2:2/20 P1:1/19
P5:7                             GPIOA(0)         1:10
P4:4                             SPI CS           1:14
P5:0                             SPI MOSI         1:18
P5:1                             SPI MISO         1:20
P8:3                             RESET            2:15
P8:2                             GPIO4            1:3
P8:1                             GPIO3            2:18

Base on this, I created the following definitions

#define     RF_PORT_SEL1           P5SEL1
#define     RF_PORT_SEL0           P5SEL0
#define     RF_PORT_OUT            P5OUT
#define     RF_PORT_DIR            P5DIR
#define     RF_PORT_IN             P5IN
#define     RF_MOSI_PIN            BIT0
#define     RF_MISO_PIN            BIT1
#define     RF_SCLK_PIN            BIT2
#define     RF_CS_N_PORT_SEL       P4SEL1
#define     RF_CS_N_PORT_DIR       P4DIR
#define     RF_CS_N_PORT_OUT       P4OUT
#define     RF_CS_N_PIN            BIT4

The problem is, I cannot get MISO to go low on the CC1120. I have attached a screenshot below, as well as the code that was ran at the time of the capture.

Below is the relevant code. I move things into main to make this post easier to read. Ultimately what happens is that trxSpiCmdStrobe() hangs at while(RF_PORT_IN & RF_MISO_PIN). I have tried inserting delays to see if maybe it was a timing issue, but no luck.

void main(void) {

    // Disable the GPIO power-on default high-impedance mode to activate
    // previously configured port settings
    PM5CTL0 &= ~LOCKLPM5;
    PJSEL0 |= BIT4 | BIT5;                  // For XT1
    
    // XT1 Setup
    CSCTL0_H = CSKEY_H;                     // Unlock CS registers
    CSCTL1 = DCOFSEL_0;                     // Set DCO to 1MHz
    CSCTL2 = SELA__LFXTCLK | SELS__DCOCLK | SELM__DCOCLK;
    CSCTL3 = DIVA__1 | DIVS__1 | DIVM__1;   // set all dividers
    CSCTL4 &= ~LFXTOFF;
    do {
        CSCTL5 &= ~LFXTOFFG;                // Clear XT1 fault flag
        SFRIFG1 &= ~OFIFG;
    }
    while (SFRIFG1 & OFIFG);              // Test oscillator fault flag
    CSCTL0_H = 0;                           // Lock CS registers

    // Put state machine in reset
    UCB1CTLW0 = UCSWRST;

    // 3-pin, 8-bit SPI master Clock polarity high, MSB
    UCB1CTLW0 |= UCMST | UCSYNC | UCMODE_0 | UCMSB | UCCKPH;

    // ACLK
    UCB1CTLW0 |= UCSSEL__ACLK;

    UCB1BR1 = 0x00;
    // Prescaler
    UCB1BR0 = 0x02;

    // Chip select
    RF_CS_N_PORT_SEL &= ~RF_CS_N_PIN;
    RF_CS_N_PORT_DIR |= RF_CS_N_PIN;
    RF_CS_N_PORT_OUT |= RF_CS_N_PIN;

    // Configure GPIO MISO MOSI CLK
    RF_PORT_SEL1 &= ~(RF_MOSI_PIN | RF_MISO_PIN | RF_SCLK_PIN);
    RF_PORT_SEL0 |= (RF_MOSI_PIN | RF_MISO_PIN | RF_SCLK_PIN);

    UCB1CTLW0 &= ~UCSWRST;

    trxSpiCmdStrobe(CC112X_SRES);
    return;
}

rfStatus_t trxSpiCmdStrobe(uint8_t cmd) {

    uint8_t rc;
    TRXEM_SPI_BEGIN(); // <- I verified CS goes low
    while(RF_PORT_IN & RF_MISO_PIN); // <-- But MISO stays high at all times and does not get past this loop
    TRXEM_SPI_TX(cmd);
    TRXEM_SPI_WAIT_DONE();
    rc = TRXEM_SPI_RX();
    TRXEM_SPI_END();
    return(rc);
}

In terms of the CC1120, are there any additional tests I can run to verify the chip is active? I probed the booster pack to ensure it was getting power, and hooked the logic analyzer to the corresponding breakouts.

  • Well,

    After reading the datasheet some more, I found a very interesting statement on reset:

    "When the power supply is turned on, the system must be reset. This is achieved by one of the two sequences described below, i.e. automatic power-on reset (POR) or manual reset:

    9.1.1 Automatic POR
    A power-on reset circuit is included in the CC112X. The internal power-up sequence is completed when CHIP_RDYn goes low. CHIP_RDYn is observed on the SO pin after CSn is pulled low (See Section 3.1.2 for more details).
    When the CC112X reset is completed, the chip will be in the IDLE state and the crystal oscillator will be running. If the chip has had sufficient time for the crystal oscillator to stabilize after the power-on- reset, the SO pin will go low immediately after taking CSn low. If CSn is taken low before reset is completed, the SO pin will first go high, indicating that the crystal oscillator is not stabilized, before going low as shown in Figure 23.


    9.1.2 Manual Reset
    The other reset possibilities on the CC112X are issuing using the SRES command strobe or using the RESET_N pin. By issuing a manual reset, all internal registers are set to their default values and the radio will enter IDLE state."


    So, as a test, I hooked up the corresponding GPIO for the CC1120 RST line to the MSP(P8.3). I toggled the pin, prior to calling trxSpiCmdStrobe and MOSI went low.

    Everything started to work after that!

    In the end, my guess is that the CC1120 was not in a state to interpret the CS signal, or process commands. Maybe a GPIO reset is required when the MSP430 boots, prior to sending any commands?

    If someone could clarify, that would be great. It is working now, but I would still like to validate my thought process.

    Thanks!

  • How was the reset line hocked up before you tested it with the MSP? The reset line cannot be left flating but must be set high until driven low for external reset.

    Siri