CC1120 SPI issue - CS pin goes low, but MISO goes low with a significant delay ?!?

Hi

I have talked to one of our designer and he can confirm that a reset will also reset the crystal. We always recommend to poll CHIP_RDYn before sending data on the SPI bus but if this is not possible you will need to insert a delay equal to the max startup- time of the crystal after waking the chip from SLEEP and also after reset. After reset you will see that CHIP_RDYn often is asserted (pulled low) much faster than the start-up time of the crystal, but to be safe, the start-up time must be used to account for worst-case timing scenarios.

Siri

Hi Siri,

Unfortunately the MISO pin cannot be directly polled by the software as it is under the control of the SPI bus peripheral controller, however I may be able to add a third GPIO to GPIO3 to poll the CHIP_RDYn directly on this pin rather. I won't be able to confirm untill the next hardware revision ... I will double check, but I am sure after a radio reset strobe command I include a fixed delay already. The other SPI bus read commands are sequentially executed after the strobe reset, and in all cases a delay just after the CS* pin is needed after CS* gets pulled low. If this isn't done I don't end up readin the correct values out of the radio chip (like part number, part version etc).

For the moment it will do with the fixed delay after CS* gets pulled low untill I look into the hw revision etc. Thanks for your info and looking into it.

Regards, mmaRn

Hello,

I am having a seemingly similar SPI issue with the CC1120. 

The issue is that sometimes when I bring CSn low, the MISO (CHIP_RDYn) stays high and never goes low.

The MCU code brings the CSn low after detecting the GPIO (set to RXFIFO at threshold or packet end) is asserted.  Once CSn is taken low, it waits for CHIP_RDYn to be low before doing anything else (i.e. no SCLK action).

I probe the 32MHz crystal with a spectrum analyzer and it indeed is still oscillating right at 32MHz so I presume the XOSC is stable.  The 3.3V supply is consistently applied too.

The issue occurs inconsistently and rarely but nonetheless show up on some custom boards I've been running.  For example, if I run one CC1120 for 24hrs, picking up ~10 packets/minute, I may see the issue occur once.  But so far, only about 1 out of 5 CC1120 units would ever show the issue.

Questions:

1. The CHIP_RDYn is actively toggling itself on MISO when CSn falls low - correct?  That is, CHIP_RDYn is not latched, thus not requiring a toggling of CSn to update.

2. Are there any reasons, other than power and XOSC crystal stability, that may cause CHIP_RDYn to stay high?

3. Is there a minimum CSn high time needed following GPIO assertion prior CSn low?  I couldn't find anything in the datasheets, user guides, errata, or forums.

-Payton

Hi

1. CHIP_RDYn does not require CSn to toggle to update

2. No.

3. No

I have never seen any problems related to CHIP_RDYn not been asserted that has not been HW related.

Are you following our reference design?

Siri

Hello Siri,

Thanks for your response.  Yes, the design is following the TI's reference design (swrc221 CC112xEM_420_470) and seem equivalent, as far as I can tell. 

Same circuit topology except slightly modified antenna matching network.  Same bypass capacitor values.  Using same crystal w/ same loading capacitor values.  I'm using a switching regulator for 3.3V supply, whereas the reference design uses an LDO.

A few other details on how I've been running and observations:

- operating in "Rx Sniff mode", waking itself up every ~2.5ms

- tried de-asserting CSn high then re-asserting low, but no difference... MISO stays high.

Do you recall what kind of HW related problems you've seen before that caused CHIP_RDYn staying high only sometimes?  EMI?  I can keep a mind out for it as I investigate further.

-Payton

The only hardware related problem I have seen in the past that causes SPI issues is soldering that don't follow the recommended temp profile destroying part of the chip. I have not seen an issue that cause the communication to fail 'randomly' just sometimes. 

- If you keep the same code but keep the chip in Rx (not sniff mode) do you see the same then?

- When the communication is working, have you measured the xosc start-up time by observing the XOSC1.XOSC_STABLE bit? Ensure that you wait at least this long for the CHIP_RDYn.

- When SPI communication fail, have you monitored the DCOUPL and RBIAS pin voltages?

Thanks for your feedback TER and suggestions.

- That's an interesting thought you have about the Rx Sniff.  I was suspecting similar.  Before implementing Sniff, I originally started using continuous Rx and didn't recall having the issue at all. Since yesterday afternoon, I've been running ~10 units back in continuous Rx to test over the long weekend.  For the few hours running observed so far, I didn't see the issue show. 

- No, haven't measured XOSC startup yet when it runs well.  I'll put this on the list of things to try.

- No, haven't monitored DCOUPL or RBIAS yet either.  I'll also have to do this.

Unfortunately, I won't be back in the lab for another 2 days, but I'll give an update then. 

Hi,

I notice this thread is still current so here's an update on the SPI problem I had.

Basically one of the issues seems to have been with the software reset I was doing. To cut a long story short (partly because of inhereted code used from a previous revision of the application software using another TI radio, but mostly because of time constraints) I modified the sequence of the radio initialisation and the SPI read/writes execute correctly and consistently.

I my previous initialisation code using another TI radio I was doing somenting like this :

{

    set_CC11XX_CS();
    TI_CC_Wait(1800);//30us
    clr_CC11XX_CS();
    TI_CC_Wait(2000);//30us
    set_CC11XX_CS();
    TI_CC_Wait(2700);//45us    
          
 

  /* Configure the SPI for read from CC11XX */
  /* read command */
   

   clr_CC11XX_CS();   // Pull down the CS pin.

    writeBuff[0] = TI_CCxxx0_SRES;    // Prepare to send Radio Reset command on the SPI bus.
    CSL_FINS(CSL_SPI_REGS->SPICMD1,SPI_SPICMD1_FLEN, 0);
    
    /* Set Command for write */

    CSL_SPI_REGS->SPIDR2 = (Uint16)(writeBuff[0] <<0x08);
    CSL_SPI_REGS->SPIDR1 = 0x0000;
    
    /* set start CMD - Write */
    CSL_FINS(CSL_SPI_REGS->SPICMD2,SPI_SPICMD2_CMD,0x02);
    
    value=0;
    do { /* Check for Word Complete status */
        value=CSL_FEXT(CSL_SPI_REGS->SPISTAT1,SPI_SPISTAT1_CC);
    }while(value & 0x02==0);

    value=0;
    do { /* Check for bsy status */
        value=CSL_FEXT(CSL_SPI_REGS->SPISTAT1,SPI_SPISTAT1_BSY);
    }while(value & 0x01==1);
    
    TI_CC_Wait(3600);  // 60us approx   
    
    set_CC11XX_CS();  // Pull up the CS pin
}

This function is always called when a radio reset and/or init is called. This code worked without any issues so I never looked back.

On the new radio I repeated the same initialisation code and the programmed the radio parameters as per usual after a boot-up. I noticed the SPI reading problems when I was verifying the radio "part number" and "part version" registers with the commands :

        partnumber = TI_CC_SPIReadReg(CC112X_PARTNUMBER);    // Part Number
        partversion = TI_CC_SPIReadReg(CC112X_PARTVERSION);    // Part Revision

When the SPI bus was not being read, I was getting 0xFF all the time. This seemed bizzare and a quick fix was to include a delay after the <<  clr_CC11XX_CS();   // Pull down the CS pin. >> instruction.

Then the partnumber and partversion were being read with the expected values ... I had no time to investigate further due to time constraints, but later I did and I changed some of the order of instructions in the power-up reset initialisation and it made the problem go away. This is unfortunately not clear to me why it was reading the wrong values, and being pressed for time with other more important tasks I was glad it worked (so far so good).

The difference in the Chip Reset code (other than adding some functions to replace the SPI write code) :

{

    TI_CC_SPIStrobe( CC112X_SRES );            // Issue Chip Reset strobe command at start.

    CLR_CC1125_CS()                    // MACRO : pull down the CS pin.
    TI_CC_Wait(2000);
    SET_CC1125_CS()                    // MACRO : pull up de CS pin.
    TI_CC_Wait(1200);

    TI_CC_SPIStrobe( CC112X_SIDLE );        // Go to idle state.

}

I had not need for the fixed delay in the SPI comms commands anymore and the Part Number and Part Version that were being read immediately after where being read correctly all the time. Without further thought I left it as is and continued with my other debugging tasks etc.

So far this issue jas not resurfaced, but one point to make is the delays I had in toggling the CSn pin were important. Too short and I was back to reading the wrong values (ie 0xFF) ...

Hope this helps ... Would be interesting to know if there is a reason for requiring the CSn pin being toggled for a fixed delay after sending a SPI_strobe command to reset the chip ?? This was for some reason also the case with the previous radio, although the order was different, but nevertheless it was put there for a good reason ...

Regards, mmar

TER said:

- If you keep the same code but keep the chip in Rx (not sniff mode) do you see the same then?

No, so far I've never seen the issue operating in continuous Rx (non-Sniff).  It seems the occasional CHIP_RDYn hangup for me is related to operating in Rx Sniff mode.

-Payton

In your code, when you pull CSn low how long do you wait for CHIP_RDYn to go low?

Regardless of if you use sniff mode or not, pulling CSn should cause CHIP_RDYn to go low but if you have gone back to sleep it will take longer time.

It would be useful if you are able to catch the event on a logic analyzator. (I see that could be difficult) but at least a plot that shown CSn low, CHIP_RDYb high and the pin voltages including the reset pin.

Originally when the issue was first encountered, the code was waiting infinitely in a while loop for CHIP_RDYn low after CSn low.  At times, it has been stuck for hours before I power cycle the device.

Then, I tried different timeouts up to ~5ms waiting for CHIP_RDYn to go low.  After timeout, CSn would be set high again, for up to 2ms, then put low and waited for CHIP_RDYn again.  And it would continue to retry infinitely, but it didn't seem to help.  The datasheet suggests 0.4ms typical for crystal startup.

It seems whenever CHIP_RDYn didn't respond, it persists until the chip is reset whereby losing the buffered packet data.

TER said:

 - When SPI communication fail, have you monitored the DCOUPL and RBIAS pin voltages?

On a failed unit where CHIP_RDYn stuck high on CSn low, the DCPL_XOSC = 1.75V, DCPL = 0, RBIAS = 0, continuously.  I assume the RBIAS are associated with biasing of RF analog circuitry, and if so, would be 0.  However, DCPL is a digital regulator output according to the datasheet, and should be high - is there any known reason why this may be stuck low?  DVDD = 3.3V still, so the digital regulator should have power.  I presume that without DCPL, SPI logic isn't functional to drive MISO.

On a working unit where CHIP_RDYn goes low, the DCPL_XOSC = 1.75V, DCPL = 1.75V, RBIAS = 1.2V, continuously.  In Rx Sniff mode, DCPL_XOSC and RBIAS signals are modulated by the Rx wakeup duty.  In Rx Sniff mode, the DCPL ~1.75V but has a some overshoot (~170mV) when Rx wakes up every 2.5ms.

These signals are the same on the working and the failed: DCPL_PFD_CHP = 0, DCPL_VCO = 0V, RESETn = high

TER said:

 - When SPI communication fail, have you monitored the DCOUPL and RBIAS pin voltages?

Payton said:

On a working unit where CHIP_RDYn goes low, the DCPL_XOSC = 1.75V, DCPL = 1.75V, RBIAS = 1.2V, continuously.  In Rx Sniff mode, DCPL_XOSC and RBIAS signals are modulated by the Rx wakeup duty.  In Rx Sniff mode, the DCPL ~1.75V but has a some overshoot (~170mV) when Rx wakes up every 2.5ms.

I can certainly confirm those values are totally correct for Rbias etc. One thing I would have liked to do is use a logic analyzer with the SPI bus analysis  option for debugging SPI buses. Unfortunately not available in our lab at this time, but may be an easier way to see what is occuring, and under what circumstances. You may be able to get you hands on one for doing the SPI bus debugging with less hassle ...

Regards, mmar

Thanks for confirming the correct voltages, mmar.  I don't have access to a logic analyzer either, unfortunately though.

From what I can tell, it seems the SPI is hanging up by not turning it's digital regulator on (DCPL=0) when CSn=0.  Is there any reason why the digital regulator would not turn on when CSn = 0? 

There is a note in the CC1120 User Guide (SWRU295E) saying that if DIV_256HZ_EN "is set the radio should not be woken from SLEEP by pulling CSn low".  By default, this bit is set.  I've been running with this bit cleared (0), but noticed no difference in prevalence of SPI hangup.  Does anybody know the nature behind this bit's note?  Is it saying that SPI may not respond (i.e. digital regulator not respond) if bit is set?

What is a safe way to select the chip, if it may be in SLEEP (e.g. during Rx Sniff mode)?

-Payton

If you are waking the chip from SLEEP by pulling CSn low (when using Sniff mode/WOR mode) there is a chance that the next tEvent0 will be wrong. This is why this should not be done. You will not risk CHIP_RDYn not being asserted.

Siri

Thanks for the clarification, Siri.

Lately, I have be running with some changes in firmware and have not encountered the SPI hangup issue since.  The primary change made was to reduce frequency of asynchronous MCU communications with the CC1120 radio. 

Previous firmware was causing the MCU to SPI communicate very frequently with the radio.  It was frequent because of inefficiently usage of GPIO3 that hardwires output 1 when Rx Sniff eWOR goes to SLEEP when GPIO2 was better (hardwires output to 0).  My guess is that chip selecting, writing/reading SPI so often and asynchronously with the WOR potentially running eventually got the radio in a bad state.  This bad state could then only be recovered from by either a RESET toggling or supply cycling.

A few additional things were done, to hopefully improve the situation or at least be safe.  1) tighten SYNC criteria (i.e. SYNC_NUM_ERROR, SYNC_THR), 2) changed to DIV_256HZ_EN = 0, 3) trimmed down PKT_LEN and FIFO_THR, and 4) making explicit cases to handle radio states IDLE/RX to avoid SLEEP state chip selection wherever possible.

Now, firmware does a more efficient job at handling radio states, strobing SWOR, and the radio's SPI has always responded.  Maybe I'm avoiding the issue seen before altogether or maybe it has just reduce the prevalence by interacting less with the radio - I'm not sure.   But, for now things are running fine.

Thanks for everyone's help.

-Payton

Hi Payton

Glad to hear that your problems have been solved.

BR

Siri