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".
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.
- Madhu Sudhan
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 “CY5670 : CySmart USB Dongle" using “CySmart 1.2”. These are the
results of our tests:
|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 Instance||XTAL32I cap value||XTAL32O cap value||Frequency measured on XTAL32I [Hz]||Frequency measured on XTAL32O [Hz]||XTAL32I pin PPM error||XTAL32O pin PPM error||Result||Notes|
|production board #1||36pF||18pF||32,765.9||32,764.1||-64.08691406||-119.0185547||KO||-|
|production board #1||36pF||16pF||32,766.3||32,764.2||-51.87988281||-115.9667969||KO||-|
|production board #1||33pF||16pF||32,766.2||32,764.4||-54.93164062||-109.8632812||KO||-|
|production board #1||33pF||15pF||32,766.4||32,764.5||-48.828125||-106.8115234||KO||faster reconnections|
|production board #1||30pF||15pF||32,766.4||32,764.6||-48.828125||-103.7597656||not tested|
|production board #1||30pF||10pF||32,767.7||32,764.4||-9.155273437||-109.8632812||KO|
|production board #2||36pF||18pF||32,765.5||32,763.8||-76.29394531||-128.1738281||OK|
|production board #4||30pF||10pF||32,767.5||32,764.2||-15.25878906||-115.9667969||KO|
|production board #5||36pF||16pF||32,765.3||32,763.5||-82.39746094||-137.3291016||KO||Powered by a lithium battery|
|production board #5||47pF||16pF||32,765.2||32,763.5||-85.44921875||-137.3291016||KO|
|production board #8||22pF||22pF||32,764.9||32,764.9||-94.60449219||-94.60449219||KO|
|production board #3||18pF||18pF||32,766.0||32,766.0||-61.03515625||-61.03515625||KO|
First connection with CY dongle
lasted for 6 minutes then it presents
|production board #9||16pF||16pF||32,766.1||32,766.1||-57.98339844||-57.98339844||KO|
|production board #6||16pF||16pF||32,765.7||32,765.6||-70.19042969||-73.2421875||KO|
|production board #5||18pF||18pF||32,765.3||32,765.3||-82.39746094||-82.39746094||KO|
|production board #5||27pF||27pF||32,764.2||32,764.1||-115.9667969||-119.0185547||KO|
|production board #8||22pF||22pF||32,766.5||32,766.4||-45.77636719||-48.828125||KO||changed 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.