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.

CC2640: Varying performances of Bluetooth depending on temperature of PCB

Part Number: CC2640
Other Parts Discussed in Thread: BLE-STACK, , CC2650

Hello everyone,

I have developed a PCB, currently at version 3 of the circuit board using CC26xx (2650 and 2640, trying out 2640R2 right now) series MCU's with BLE-stack. But I have encountered an issue in hardware with my latest circuit which I haven't noticed before in earlier versions of my PCB and I am having troubles finding the cause.

So first of, let's describe the system:

- For my graduation project, I made a PCB for a company which allowed their custom UART-protocol to be communicated through BLE. This is the basic principle simply put. It's meant to be a system made for service engineers in order to diagnose their products through their UART-protocol with a Bluetooth application.

- The latest PCB consists of DC-converters (one LDO, one voltage shunt and one boost-converter), RX/TX - buffer gates, LEDs, TAG-connect for programming,  PCB IFA-antenna, 24Mhz and 32kHz crystals, a Microchip LiPo charging circuit and some other basic capacitors and resistors to make everything work.

- The software running on the system is a modified Project_Zero project using services I generated with Bluetooth Developer Studio. The UART-task is placed in a seperate RTOS task and with messages through the message queue, the generated task with Bluetooth Developer Studio is notified.

Now the problem:

- I have made 10 PCB's using CC2650 and CC2640 MCU's and soldered them using solder paste and placed them in the oven once I was done placing the SMD components.

- Out of these 10 PCB's, only one seems to be running BLE-stack smoothly. When I connect to it using a Samsung Galaxy Tab A 10.1 2016, and turn on the notification where all the UART-messages are sent to, I notice a significant amount of package loss. This protocol has not changed, and always worked fine.

- Additionally, when using other devices to test (iOS and other android devices as well), one seems to suffer data loss, and the other doesnt. But in older versions of my PCB, all devices do not suffer any package losses at the aforementioned notification UUID.

- The amount of dropped packages from the notification UUID differs per PCB, where out of 10, one seems to have perfect performance.

Solutions I tried and things I noticed during testing:

- Replacing MCU, did not change anything.

- During replacing I did notice one thing. When the PCB is still hot, the Bluetooth service functions perfectly until it cools down again. I thought this might have something to do with oscillators as these might differ in performance when temperature changes. I replaced the crystals (32kHz and 24MHz) and nothing was solved.

- During debugging, the Bluetooth worked perfectly fine.

- All other tasks in the RTOS are not affected (uart is still communicating as it should). Only Bluetooth seems to be affected.

- I removed all power components, so it is also not caused by the switching frequency of the boost-converter.

- Powering from a Launchpad without debugging does not solve the problem.

- Adding extra solder to all SMD components of the antenna did not solve the problem.

- Pressing the MCU while communicating with tablet did not affect communication, so it's not caused by connection of the pads.

I have tried countless things and I cannot seem to find the cause of this problem in this latest PCB as nothing on the side of the MCU and antenna has changed in layout. Before I have to get my hands on a Spectrum analyzer, I wanted to try asking in this forum, perhaps someone can help me with this problem?

A very simple solution would also be: using a different device than the Samsung Galaxy tab 10.1, but I want to find the cause of this problem first...

I will add schematics and layouts if this is necessary.

Thanks in advance,

Chun-Pong Tang

  • Hi Chun-Pong Tang,

    Your crystal theory might still be correct. Have you checked the frequency accuracy of both oscillators? 

    The 32 kHz clock can be routed to an IO pin and you can measure with a frequency counter. Refer to the IO chapter in www.ti.com/lit/pdf/swcu117 

    The 24 MHz crystal you can measure by controlling the chip from SmartRF Studio and measure the output on a spectrum analyzer.

    Cheers,
    Fredrik

  • Hi Fredrik,

    Thanks for answering! I will be back in the office coming monday, I will try doing that by then and update this thread.

    Regards,
    Chun-Pong Tang
  • I have mapped the 32kHz crystal to an DIO pin and measured it with a scope. The frequency is about 32,77kHz so it looks fine to me. Image added below.

    I was also wondering if I could measure the 24MHz crystal by just toggling IO in assembly in an infinite while loop instead of measuring it with a spectrum analyser?

    Also for additional information on the layout, an image of the circuit on the MCU side:

    Kind regards,

    Chun-Pong Tang

  • 32.77 kHz is 60 ppm off, so it is not exactly spot on.
  • I tried to measure the same pin with the same method on the CC2640R2 launchpad, and got the same result of 32,77kHz.
  • Is the instrument rounding off? Can you measure with a proper frequency counter?
  • Ah, that works a lot better. I now used a Keithley DMM7510 in frequency mode.

    Launchpad CC2640R2: stable 32.76795 kHz
    Custom board: varies between 32.77013-32.76986 kHz

    EDIT: One of the older versions where Bluetooth worked a lot better also had a frequency between 32.77013-32.76986 kHz

  • these last few days I have tried to edit the low frequency crystal multiple times (by exchanging load capacitors for different values in case my stray capacitance would be problematic) without any improvement in BLE performance. The datasheet of the CC2640 also indicates that the max tolerances of the crystal are +/-500ppm, which I do not exceed. 

    I still need to test the 24MHz crystal for stability with a spectrum analyzer. For a quick test I tried to measure the accuracy of a PWM signal, where I got 10,077kHz as a result from a 10kHz PWM. But I figured this measurement is useless as it probably does not represent the stability of the 24MHz clock?

  • Last update for now. The problem is not completely solved, but I found where the cause is.

    By turning off the power saving mode, I prevent my code from using my externel 32kHz oscillator. Now it seems to work perfectly fine. It is however only a temporary solution, but now I know it's a PCB layout problem.