Smart Bluetooth Forum Discussions

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

has anyone dealt with similar errors?

Thanks.

Does WICED Sense 2 kit work with iPhone 5 SE? I tried to look for its app on my iphone 5 se and I could not find it. Light Blue LE can see it.

Thanks for updating the other recent threads on the same topic.

We recently received several pcs of the fail devices from customers.

They have used the devices for several months, but fail to power up recently.

When we send the fail devices to the factory and replace the 20737S with a new 20737S, it works.

The situation is similar to the problem reported. Do you have any suggestion?

Regards,

Brian

Hi I'd like to program some SK6812 LED strip with the WICED BLE.

There is some ARM0 sample code out there for NXP LPC810 ARM0 competitor or STM32

This library uses a bitbanging approach with active CPU waiting

GitHub - cpldcpu/light_ws2812: Light weight library to control WS2811/WS2812 based LEDS and LED Strings for 8-Bit AVR mi…

http://www.szledcolor.com/download/SK6812RGBW.pdf

How would you proceed to translate the code for Wiced ?

Does Wiced has API for bitbanging on any GPIO ?

light_ws2812-master\light_ws2812_ARM\light_ws2812_cortex.c

light_ws2812-master\light_ws2812_ARM\light_ws2812_cortex.h

Other solution would use the PWM and DMA is there sample code for that for the Wiced SDK

We use the BCM20736S and we found some strange behavior of GPIO P33:

We want/must to use this GPIO P33 as an ADC input.

After power on or reset everything is OK, but after wakeup from LPM this GPIO is set to output !!!

(see following trace logs)

What is the reason for this ?

How could we avoid this? Is there a software workaround?

We don't want to change our hardware PCB design (if possible)!

Trace (C-code):

UINT16 cfg1 = gpio_getPinConfig( 0, 4);

UINT16 cfg1a = gpio_getPinConfig( 0, 8);

UINT16 cfg2 = gpio_getPinConfig( 2, 0);

UINT16 cfg2a = gpio_getPinConfig( 2, 1);

ble_trace2("cfg1:%02x  cfg1a:%02x", cfg1, cfg1a);

ble_trace2("cfg2:%02x  cfg2a:%02x", cfg2, cfg2a);

After PwrOn/Reset:

12:45:00 - CreateFnc

12:45:00 - cfg1:600  cfg1a:600

12:45:00 - cfg2:600  cfg2a:600

12:45:00 - SetLpm

12:45:00 - cfg1:0b  cfg1a:600

12:45:00 - cfg2:0b  cfg2a:600

12:45:00 - Entering Lpm.

After wakeup:

12:46:11 - CreateFnc

12:46:11 - cfg1:0b  cfg1a:600

12:46:11 - cfg2:0b  cfg2a:4600  // why is this GPIO P33 now set to output ??? !!!

another question .my 920737TAG03-HWUM100-R   can not download my app . It always remand me that ( i use wiced smart )

I have tried as what it said but it always remand me this .

Hi,

Are there any conditions when bleappfwu_watchdogExpired(0) should *NOT* be used?

For instance, is it OK to commence bleappfwu_watchdogExpired(0) at the following timing?

- DeepSleep

- Advertising

- Connecting

- Upon the reception of Write request

Hi,

I'm using a BCM92073X_LE_KIT, connected to WICED SDK, it has been working fine for the past few months, however today it has stopped working.

Nothing can be seen through the UART terminals.

When we try to upload a program to the tag it says no device detected, even after following all procedures outlined in the WICED Smart™ Development System Quick Start Guide. (i.e. Appendix 😧 Recovering a Corrupt WICED Smart Tag).

It seems as though the tag may be unrecoverable...

Has anyone had a similar issue? Is there any other way to recover it?

Description:

we provide a BLE 20737s module to be as master on electric machine, like air-cleaner.
It also receive the sensor value broadcasting from other end-device(slave).
Our customer takes their air-cleaner to do the RF interference test(SGS RF);

it fails at 2.4G RF test but other frequencies are ok.
Coz BLE is operating on 2.4G band, if trying this 2.4G co-channel noise test, is it a correct test to test on 20737s
or we need to avoid this same band BLE4.0 test; i know 737s is low-energy power and it should have error packet
received in Rx path of master module. Is my idea right or if no, how to pass this test case  or Cypress has
also that kind of test-report or not???