CC26xx HW Troubleshooting

From Texas Instruments Wiki
Jump to: navigation, search

This guide will try to cover the most known challenges seen when using the CC26XX in your HW design.

When asking for support on HW issues it is expected that you have followed this guide first. When asking for support on E2E, please include your findings as well as a copy of your schematic and layout (pdf or image). In the cases where a full schematic cannot be shared, please include the parts related to CC26XX.

Initial board bringup

If your board cannot be connected to with JTAG there might be electrical or connection issues with the board. The following items should be verified:

  • A supported debugger is used.
  • TCK / TMS / RESET / GND is connected to debugger. For debuggers with a VDD sensing pin (VDD_SENSE), this should be connected to the board supply and the board should be powered by an external power source. Debuggers without a VDD sensing pin requires board supply voltage to be approx the same as the debugger voltage (typically 3-3.3V).
    • Debuggers supporting only regular 4-pin JTAG need TDI and TDO connected.
    • If using XDS200, make sure the reset pin on the CC2640 is connected to the correct reset output from the debugger
  • All VDDS* pins are connected to the supply and they have the same voltage as the supply.
    • If using a board in external regulator mode:
      • VDDS_DCDC is connected to GND.
      • DCDC_SW is floating or connected to GND
      • DCDC is disabled in software by modifying the customer configuration area (*ccfg.c). TI's examples always have the DC/DC enabled.
  • The EGP (ground pad) is properly connected to the ground plane through multiple vias (and soldered correctly)
  • The voltage on VDDR and VDDR_RF is approximately 1.68V.
  • The voltage on DCOUPL is approximately 1.28V.
  • Device current draw is approximately correct. If the device flash is empty it will enter bootloader mode after power up and draw approx 6-7mA.

If all the above seems correct but the device can still not be connected to, the only option to verify that the device is operating correctly is to connect to the device using the on-chip bootloader and run CMD_PING to check whether a response is received (UART need only to synchronize with the device by writing 0x55 0x55).

To rule out any IDE (IAR/CCS) related issues, use SmartRF Flash Programmer 2 with a supported debugger to check whether the device can be recognized or not.

Software bringup

Once you have confirmed the HW measurements above are within specification, it is recommended to load a minimal bring up firmware configuration. This methodology is preferred since you can verify that your board file changes are working without introducing variables from complex application code. TI recommends using the simple_peripheral project (non-OAD configuration) with changes to disable GPIO access along with the proper RF Front End and Bias configuration. This procedure is explained with more detail in the the online Initial Board Bringup section of the BLE SW User's Guide "Running the SDK on Custom Boards". Note that all TI sample applications assume the internal DC/DC is used, so you must have all required external passive components placed or modify the CCFG accordingly to match your power source.


BLE Connection issues

My device is advertising but fails to connect, what is wrong?

This typically happens if the 32.768kHz crystal is not connected or fails to start up. When the device boots it starts up by using the internal 48MHz RC Oscillator / 1536 as source for the LF system clock, which is used for the RTC. This causes the RTC to tick at 31.25kHz instead of 32.768kHz(note that this is different from using the 32-kHz Crystal-Less Mode described in Section 6.6 in our SDG. When trying to connect the device will consequently wake up too late for the connection event and a supervision timeout will occur. Measure the 32-kHz system LF clock by outputting the clock on a DIO/PIN by following the procedure in the CC26xx TRM, Section 11.3.3 "Map 32-kHz System Clock (LF Clock) to DIO/PIN" (docID SWCU117 Rev F).

Add the 32.768kHz crystal and/or make sure the crystal is within the requirements in the CC2640 datasheet. The load capacitors must also be dimensioned correctly to get the crystal to oscillate at the right frequency.

You can also make sure what clock source is being used in software through driverlib API (found in C:\ti\tirtos_cc13xx_cc26xx_2_20_01_08\products\cc26xxware_2_24_02_17393\driverlib\osc.c):
if(OSC_XOSC_LF == OSCClockSourceGet(OSC_SRC_CLK_LF)) {}

Verify that the BLE-Stack has been configured with the correct Sleep Clock Accuracy. The default setting is 40 ppm and can be adjusted with the HCI_EXT_SetSCACmd API, see hci.h or the TI Vendor Specific API Guide included in the SDK.


Radio performance issues

Sensitivity is significantly lower than stated in the data sheet

  • Ensure you are using the correct front end and bias mode configuration and that you have followed the reference design closely.
  • Check that your design is in accordance with the HW design checklist for CC2640
  • Disable the DC/DC through the customer configuration area (*ccfg.c). If this helps then your board layout might need to be updated due to too much noise on power or ground. Please request a review of your schematic and layout on E2E.


Output power is lower than expected

  • Ensure you are using the correct front end and bias mode configuration and that you have followed the reference design closely.

Power consumption issues

My device draws more current than the 1uA expected in Standby, what is wrong?

First of all, make sure you are measuring the current correctly. If using the SmartRF06EB, remove all jumpers on the board and measure current across the VDD_TO_EM jumper. If measuring with a digital multi-meter (DMM), you typically see current draw jump between 0 and 5uA due to periodic recharges of the VDDR capacitor which the DMM is too slow to sample.

See this application note for more details: Measuring Bluetooth Smart Power Consumption

There can be a number of reasons for this. The most common are:

  • Software-related issues
    • To check what the board is drawing in Standby, remove everything from main() except BIOS_start. This way only the Idle thread will run and the device will be put into Standby mode .
  • Floating input pins on the CC26XX or floating pins on other IC's on the board.
    • The CC26XX boots up with all pins high impedance (both input and output disabled). If possible, remove all other IC's on the board except CC26XX and check current when pins are not initialized ( do as suggested for software-related issues). If this is not possible, configure all pins to be pulled to a defined level through software.
  • The 32.768kHz crystal is not connected or fails to start up. This causes the 48 MHz RC Oscillator and the supply system to stay on, preventing Standby mode.

Add the crystal or use a crystal with load capacitors within the range given in the data sheet.