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.

CC2564: Bluetooth Module PAN1326 does not power up

Part Number: CC2564

We use the Bluetooth module PAN1326 where the chip CC2564 is used. According the datasheet, a power up sequence has to be done to complete the power up. A successfull power up gets indicated by a high to low transission of the RTS:

On our setup it looks like as follow:

We already assembled 90k of the PAN1326 on our products. All of them are working. But since a couple months, we got a high failure rate of the PAN1326 which do not startup well anymore. The RTS does not go low after 100ms:

The RTS will go low, but sometimes it takes more than 20s. We have nothing changed on our design. Why does the RTS does not go low within 100ms? According our measurements, all of the timings and voltages are within the specification.

  • Greetings Marcel,

    I will be looking into it at the beginning of next week and get back to you shortly.

    Best Regards,

    Jessica

  • Hi Marcel,

    When powering up, Is VDD_IO and VDD_IN stable before releasing NSHUTD? Othwerwise, the CC2564 may not initialize correctly.

    When powering down, is nSHUTD low before VDD_IO and VDD_IN are removed?

    BR,

    Seong

  • Hi Seong

    While powering up, the VDD_IO and VDD_IN are stable before releasing NSHUTD as you can see on following picture:


    At the current design, there is no capacitor added on the VDD_IN for stabilization the supply coltage. To verify this, I added a 100nF. But this doesn't help. I could find any recommendatiion on the CC2564 datasheet regarding this?!

    While powering down, NSHTUD is low before VDD_IO and VDD_IN are removed:

    Currently I have one module where we can reproduce the failure at about 50%. We have more modules, but most of them show the failure seldom and randomize.

    If the failure happens (RTS does not go low within 100ms), You can wait about >20s and then the RTS goes low. It means the RTS goes always low, but sometimes you have to wait more than 20s.

    Since 3 month we have a failure rate of approx. 3%.

    Best regards
    Marcel

  • Hi Marcel,

    See this related thread.

    Have you verified that the clocks are stable? 

    Everything else looks good to me.

    BR,

    Seong

  • Hi Seong
    We have found the problem. Unfortunately we have a shift of the source clock which doesn't match anymore with the Bluetooth clock frequency tolerance of 250ppm. We have measured a clock of 32750kHz instead of 32768kHz +/-8Hz

    Thank you for your support!
    Best regards

    Marcel