4 Replies Latest reply on May 7, 2017 7:54 PM by BoonT_56

    BLE disconnects in deep sleep for board production version

    sigi_2251526

      I'm developing a BLE peripheral that has to go in deep sleep and keep connecting to a central device using CY8C4247FNI-BL483 and I'm switching from a "developing" board to a miniaturized board for production. Loading the same firmware on both boards I see that on the developing board everything works fine. On the production board I find that the peripheral device connects to the central, it negotiates successfully for a longer connection interval (500 ms with a 5s supervision TO and slave latency to 0) with the central, tries to go on deep sleep and, after supervision TO period has passed, the central device receive a "Connection Terminated Notification" event and the connection goes down. As a central device, for testing purpose, I'm using "CY5670: CySmart USB Dongle" and CySmart. I've noticed that if the BLESS doesn't go in deep sleep it maintains the connection up without any trouble.

       

      The main differences between the two board versions are:

       

      1-Different antenna routing network.

      2-Different microcontroller package (from QFN to WLCSP)

      3-Different layout and component dimensions for the WCO and ECO crystals involved.

       

      I think the difference at point number 1 is not the the probable cause of the issue otherwise I will see connection problems even if the device doesn't go in deep sleep. Reading some Cypress application notes (AN92584 and AN95089 in particular) seems that all the clues lead to a WCO inaccuracy that may cause an improper connection timing between the devices. In fact even if the WCO crystal capacitors have the same values between the two board versions, these capacitors have different aspect ratio (they're smaller on the production board and the crystal is smaller also) and the layout of the connection between the crystal and the microcontroller is significantly different for the two boards. In production board the microcontroller and the crystal are put in different layers (top and bottom) of a 4 layers PCB and connected through VIAs. The inner layers are for VDD and GND. Could this be the problem? Should I have to "tune" the WCO crystal capacitors because the layout adds too much parasitic capacitance and this drifts significantly the WCO from the nominal value? Since the capacitor tuning operation is quite difficult for us to accomplish I would like to be pretty sure for this to be the possible issue cause before trying to operate in that way. In fact, if possible, a firmware workaround is preferable. By the way, is there a possibility to track this eventual issue somehow on the firmware by some BLE stack calling or system calling? CyBle_Start() returns "CYBLE_ERROR_OK".

       

       

      Thank you,

       

       

      Simone

        • 1. Re: BLE disconnects in deep sleep for board production version
          BoonT_56

          This forum supports only the CYW2073x devices. For your query, you will have to create a support case using "MyCase" at the

          following URL:

           

          www.cypress.com/mycases

          • 2. Re: BLE disconnects in deep sleep for board production version

            Hi Simone,

             

            As you suspected, The BLE RF Performance is very much dependent on the ECO and WCO Crystal's tuning. As the issue is noted only when deep sleep is enabled, the issue could be with the WCO, but WCO cannot be tuned by the firmware unlike ECO.

             

            Please characterize the performance of your WCO clock (ppm and other essential parameters specified in AN95089) and make the hardware changes as recommended in the App Note.

             

            Regards,

            - Madhu Sudhan

            2 of 2 people found this helpful
            • 3. Re: BLE disconnects in deep sleep for board production version
              sigi_2251526

              BoonT_56 and madhul_36

               

              I've got an update about the project. We've tried to test multiple production version boards and they show different behaviours:

              - We have tested 11 instances of production version board.
              - We have tested the boards with an Android application which we have self-implemented (with the
              extra feature that the application tries to reconnect automatically with the device in case of a
              disconnection) and with “C
              Y5670 : CySmart USB Dongle" using “CySmart 1.2”. These are the
              results of our tests:

               

              Instance Result Error Description
              1 KO It presents an unstable connection. When the CY5670 dongle is used it disconnects
              after the timeout period as indicated on the connection parameters
              updated before (after early 5s). With the Android app it disconnects
              similarly as with the dongle but it is able to reconnect. A periodic
              disconnection is noticed every early 20 seconds. The automatic
              reconnection is achieved with success but it may need more time respect a
              board which is working good. Rarely may it stays connected for a longer
              time respect the noted 20 seconds.
              2 OK The device seems to work well.
              3 KO See instance number 1.
              4 KO See instance number 1.
              5 KO See instance number 1.
              6 KO See instance number 1.
              7 KO The firmware execution starts with success. The board goes in advertise
              and can be detected from both the dongle and the Android application but
              it can’t connect with the central devices. The software often resets .
              8 KO See instance number 1. In addition it’s hard to detect the device on a scan
              from central devices.
              9 KO The firmware execution seems to work well but signal emitted from the
              device is quite weak (circumstance observable reading RSSI parameter from
              CySmart). It’s not possible to achieve connection.
              10 KO See instance number 7.
              11 KO See instance number 7.

               

              The problem reported in my original post regards only a part of the statistic involved in the tests but we've tried  the same to follow the indications of application note AN95089 for the instances 1,3,4,5,6 and 8 trying to characterize the performance of the WCO as indicated. The following lines show in chronological order the operations that we performed, the frequency measurements, the PPM of error in frequency and test results for the production board tested. In the following table with "KO" I mean that the problem descripted in the precedent table persists for the indicated board.

               

                     

              Board InstanceXTAL32I cap valueXTAL32O cap valueFrequency measured on XTAL32I [Hz]Frequency measured on XTAL32O [Hz]XTAL32I pin PPM errorXTAL32O pin PPM errorResultNotes
              Development board36pF18pF32,76732,766.0-30.51757813-61.03515625OK-
              production board #136pF18pF32,765.932,764.1-64.08691406-119.0185547KO-
              production board #136pF16pF32,766.332,764.2-51.87988281-115.9667969KO-
              production board #133pF16pF32,766.232,764.4-54.93164062-109.8632812KO-
              production board #133pF15pF32,766.432,764.5-48.828125-106.8115234KOfaster reconnections
              production board #130pF15pF32,766.432,764.6-48.828125-103.7597656not tested
              production board #130pF10pF32,767.732,764.4-9.155273437-109.8632812KO
              production board #236pF18pF32,765.532,763.8-76.29394531-128.1738281OK
              production board #430pF10pF32,767.532,764.2-15.25878906-115.9667969KO
              production board #536pF16pF32,765.332,763.5-82.39746094-137.3291016KOPowered by a lithium battery
              production board #547pF16pF32,765.232,763.5-85.44921875-137.3291016KO
              production board #822pF22pF32,764.932,764.9-94.60449219-94.60449219KO
              production board #318pF18pF32,766.032,766.0-61.03515625-61.03515625KO

              First connection with CY dongle

              lasted for 6 minutes then it presents

              disconnection problems

              production board #916pF16pF32,766.132,766.1-57.98339844-57.98339844KO
              production board #616pF16pF32,765.732,765.6-70.19042969-73.2421875KO
              production board #518pF18pF32,765.332,765.3-82.39746094-82.39746094KO
              production board #527pF27pF32,764.232,764.1-115.9667969-119.0185547KO
              production board #822pF22pF32,766.532,766.4-45.77636719-48.828125KOchanged WCO crystal with
              ab26trb-32.768khz-t from Abracon

               

              As showed it seems that the problem isn't caused by a WCO PPM value that is out of range (all measurements are inside the 500 PPM absolute tolerance value specification). So we haven't any clue on where to operate to resolve the problem.

               

              In addition we've tried to perform the following operations:

              - we've tried to double the WCO startup time but that didn't resolve the issue.

              - we've checked from CY dongle that the RSSI values measured in advertising for the development board and the production boards are similar.

              - we've conducted an X-ray test for checking the solderings of the components for a production board instance (#5) and they are correct.

               

              Furthermore the firmware works correctly for all the development board that we have assembled and programmed.

               

              Since the resolution of the problem has becomed crytical for us I'm asking if there are any different "channels" on where we can have quicker assistance as we communicate you the results of our tests.

               

              Thank you,

              Simone.

              • 4. Re: BLE disconnects in deep sleep for board production version
                BoonT_56

                Hi Simone,

                 

                This community supports only CYW2073x products. Please create a "My Case" at the following URL so that the

                issue can be directed to the right people.

                 

                Support & Community | Cypress Semiconductor

                 

                 

                madhul_36

                1 of 1 people found this helpful