Custom Board with CC2640 Cannot Run Standalone

Hello Amos,
Impedance matching of the antenna should not in any way relate to the fact that it works better while in debug mode compared to standalone. It could be a issue with the 32 kHz LS Clock source.

Did you follow our reference design?
There are some guidelines and Troubleshooting guides on ti.com/ble-wiki under the Design Resources section:
processors.wiki.ti.com/.../CC26xx_HW_Checklist
processors.wiki.ti.com/.../CC26xx_HW_Troubleshooting

Hi Eirik,

   I already used crystal 32.768 kHz, but capacitor is 22pF, not 12pF which used by CC2650 LaunchPad.

I measured crystal output pin, it has 28 kHz, 360mV clock.

Is this value okay?

Thanks for your reply

Your xtal frequency is too off, then your device will easily missed the expected wakeup time when you are not running in debug mode. In debug mode, the device will never go down to standby due to the JTAG domain is on. When not in debug mode + power saving is enabled, once device enters sleep, the system clk source will be sclk_lf which is 32kHz xtal. The RTC will schedule wakeup based on the xtal, however, your design is pretty off, which might be the reason you see that you are having trouble connecting to the device.

Hello Amos,

Happy to see you design in CC2640. We have lot of comments so please bear with us :)

As Christin stated, your design should follow the ref design. If you used an 32 kHz XTAL with the same load capacitance rating as one the CC2650LP,  you must use 12pF load caps. The 22 pF currently used will result in a total load cap of more than 12 pF which is above the stated maximum rating given i the CC2640 datasheet (section 5.9 32.768-kHz Crystal Oscillator (XOSC_LF)). A too high load capacitance can result in lower frequency, unstable operation or even failure to start the crystal oscillator. In this case the clock is ticking but at a different speed than what the RTOS+BLE application is expecting.

Compare to the CC2650EM-5XD Reference Design. Specifically for radio SoC PCB layout, it is critical to copy the reference design as closely as possible to get optimal performance. You should use more decoupling capacitors on the VDDS and VDDR lines as done in the reference design. I do not recognize the balun used for the RF pins. Is it one of these given in the link below? If the balun is not designed and matched for the CC2640 input impedance, the RF performance will not be optimal: processors.wiki.ti.com/.../CC26xx_Integrated_Baluns

There are some useful design resources given in ti.com/ble-wiki:
processors.wiki.ti.com/.../CC26xx_HW_Checklist
http://processors.wiki.ti.com/index.php/CC26xx_HW_Troubleshooting

Even tough all the mention above is important I would start by changing the load caps on the 32 kHz XTAL to see if that works, but bear in mind there could be other issues.

Hi Eirik/Christin,

    I had tried 10/12pF, but the problem is the same. I measured the crystal output pin, it has 32.25 kHz, 360mV sine wave.

If I disable POWER_SAVING define, it can run well with standalone.

My Crystal spec are:

FREQ.             32.768 KHz

TOL.                +/-20PPM (-40~+85)

LOAD//ESR     12.5pF    //90K ohms

Thank you for your help

32.25kHz is still pretty off... Can you route your clk signal to an IO and check out the frequency from the IO. It's not recommended to probe the xtal pins.
You only need to add the code below and include the needed files:

IOCPortConfigureSet(IOIDn, IOC_PORT_AON_CLK32K, IOC_STD_OUTPUT);
AONIOC32kHzOutputEnable();

Hi Christin,

     I tried dip crystal 32.768 KHz, and 12pF capacitor, and add code to probe wave form in gpio pin:

    IOCPortConfigureSet(GPIO_LED, IOC_PORT_AON_CLK32K, IOC_STD_OUTPUT);
    AONIOC32kHzOutputEnable();

I can get the correct frequency 32.768 KHz, but the problem is the same.

Thank you for help

Hello Amos,

Did you go through the checklists mentioned above?

Don't you have any decoupling on the VDDS line and VDDS pins 11, 28 and 18?

Hi Eirik,

I had checked from checking list.  There have some decoupling capacitor on my board.

The attachment is my schematic.

Protel Schematic.pdf

P.S. My program is porting from MultiRole.

Thank you for your help

Hi Eirik,
I also find a strange situation: If I touch any pin of 32.768 KHz crystal with my finger or probe, the system will be reset. I have no idea about this.

You should not touch any xtal pin, your finger can cause overall capacitance change which might stop the crystal. Please do not do that.

Are you powering your device through battery or a power supply?

Hi Christin,
I use power supply to power on the device.

Thank you for your help

Hi,

When you stated it does not run without being in debug mode, does it mean it just stops? Can you try to use internal RCOSC_LF as sclk_lf source to see if it helps?
You can follow the application note below to configure device using RCOSCLF
www.ti.com/.../swra499

Hi Christin,

    Sorry reply too late.

The cpu is still run without in debug mode, because the led can twinkling every 5 seconds. I think this is this problem of power saving. If I un-define POWER_SAVING, and run without in debug mode, my phone can discovery and paring to device.

Thank you for your help.

can you try to enable power saving and use RCOSC_LF instead? If that fixes the problem, then there must be something we have not noticed with the 32kHz xtal.

Hi Christin,

  I had tried enable power saving and use RCOSC_LF, the problem is the same.

My test steps are:

1. Remove external crystal 32.768 KHz

2. include "rcosc_calibration.h" in main.c ( I disable USE_RCOSC define in rcosc_calibration.c)

3. Add RCOSC_enableCalibration(); in main() after board initialize

4. In debug mode, my phone can discovery and paring to device. Without debug mode, my phone can discovery the device sometimes, but pairing always fail.

I will also find a support from TI's FAE next week.

Thank you for your help.

Hi Amos,

A question on the side here: What is the part number of the balun you are using?

Cheers,
Fredrik

You also need to modify the ccfg.c to change the sclk_lf source from 32k xtal to RCOSC_LF.

Hi Fredrik,

My balun is

Thank your for your reply

Hi Christin,

  I tried to use internal oscillator again, the problem is the same.

My test steps are:

0. My Environment are:

    CCS 6.2.0, ble_sdk_2_02_00_31 

1. Import simple_peripheral_cc2650em_stack and simple_peripheral_cc2650em_app

2. modify chip define to CC2650DK_5XD, add USE_RCOSC define

3. in simple_peripheral.c,

  change

  #include "rcosc_calibration.h"

to

  #include "C:/ti/simplelink/ble_sdk_2_02_00_31/src/common/cc26xx/rcosc/rcosc_calibration.c"

4. modify ccfg.c, change SET_CCFG_MODE_CONF_SCLK_LF_OPTION to 0x03 (also tried to 0x00)

#ifndef SET_CCFG_MODE_CONF_SCLK_LF_OPTION
// #define SET_CCFG_MODE_CONF_SCLK_LF_OPTION            0x0        // LF clock derived from High Frequency XOSC
// #define SET_CCFG_MODE_CONF_SCLK_LF_OPTION            0x1        // External LF clock
// #define SET_CCFG_MODE_CONF_SCLK_LF_OPTION            0x2        // LF XOSC
#define SET_CCFG_MODE_CONF_SCLK_LF_OPTION               0x3        // LF RCOSC
#endif

5. In debug mode, my phone can discovery and paring to device. In standalone mode, my phone cannot discovery the device.

Thank you for your help.

Can you trace your VDDS with oscilloscope to see if the device is actually stuck on reset?