Smart Bluetooth Forum Discussions

Has anyone been able to run wiced sense source code with virtual emulator using android studio? Like to know which emulator is being used if you have it running.

So I think I may have bricked my BCM20736S with a bad firmware upgrade, and I'm wondering if I can run the recovery process on it without having access to the SDA pin?

What happened, was I was writing a script to increment the DLConfigBD_ADDRBase each time before it uploads. However, I changed the BTP file to have a new address, and accidentally did not build a new hex file with CGS, so ChipLoad uploaded the OLD hex file with the OLD address but used the NEW BLE address in the BTP file. Not sure if that's what did it, but the chip stopped working after that; it doesn't even show up as a USB device any more.

So is there a way to run a recovery on the chip? I only have access to the HCI TX/RX pins, and the RESET pin on the module. The hardware quick start guide mentions having to press a button on the tag which I don't have. Any ideas on how to get around this, or is that chip just bricked forever?

Can someone point me to a list of the service and characteristic UUIDs available for the accelerometer, gyro, temperature, etc on the WICED sense Bluetooth Smart Sensor Development Kit.  I went through the source code for the Android app and could only find the battery level characteristic.  Thanks. 

Greetings,

Is anyone out there building projects old-school -- from the command line?

thank you

According to The bluetooth core 4.1  spec the advertisement packets should contain the advertiser's BD_ADDR for example if the PDU type is ADV_IND the payload will have the AdvA (6 byte BD address) and AdvData ...

Is this information available to central side? (ie, an iOS or Android device?) ... it seems like some of this raw data is not available. Why would that be the case? What if someone wanted to add data to an advertisement packet?

Greetings,

Has anyone tried using the Black Magic Probe or some sort of OpenOCD compatible device?  I'm looking at alternatives to JLINK.

thank you

Hi,

  I'm using 20732 as central role in creating connection to peripherals which is also 20732.

  But one critical issue I found is that after connection down event occurs, the 20732 as the central role is not able to scan anymore.

  I've checked post Re: unexpected "bleprofile_connDown stop Idle Timer", and also adding the retry (creating connection again), but still got the same issue.

  Some clue as I found in my trial:

  1. retry upon the disconnection cause (0x3e) is working. but failed in cause (0x08)

Retry is made as below:

blecm_CreateConnectionCancel ();

blecm_CreateConnection (

        blecen_cen_cfg.high_scan_interval,

        blecen_cen_cfg.high_scan_window,

        blecen_cen_cfg.init_filter_policy,

        HCIULP_PUBLIC_ADDRESS,

        (char *) addr,

        HCIULP_PUBLIC_ADDRESS,

        blecen_cen_cfg.high_conn_min_interval,

        blecen_cen_cfg.high_conn_max_interval,

        blecen_cen_cfg.high_conn_latency,

        blecen_cen_cfg.high_supervision_timeout,

        blecen_cen_cfg.conn_min_event_len,

        blecen_cen_cfg.conn_max_event_len);

  2. when issue happen (no more scanning working), I can't enable the scanning again by doing disable scan and enable it again:

a. blecm_setScanEnable (0, blecen_cen_cfg.filter_duplicates)

b. blecm_startScan (

    blecen_cen_cfg.scan_type,

    blecen_cen_cfg.high_scan_interval,

    blecen_cen_cfg.high_scan_window,

    blecen_cen_cfg.scan_adr_type,

    blecen_cen_cfg.scan_filter_policy,

    blecen_cen_cfg.filter_duplicates);

Any solution or workaround for this case? At least I need central to be able to scan and make connection to peripheral again.

Hello,

In our use case, the application in Slave side calls bleprofile_sendNotification() to send data to Master.

Sometime we are observing Master skips connection windows consecutively which results in buffer overflow in Slave side.

Since the application in Slave side keeps calling bleprofile_sendNotification() without knowing the status of

previous notification data (i.e., without checking if the previous data actually sent over the air),

it seems like some of notification data are being lost.

1) Is there any way for the application to check if bleprofile_sendNotification() was successfully queued?

2) What is the max number of Notification data queued in BLE stack?

3) Anyway to check if notification TX buffer is available before calling bleprofile_sendNotification()?

Thanks!!

D:\WICED\WICED-Smart-SDK-2.1.1\WICED-Smart-SDK\include\bleapp.h;

bleapp.h such settings.

enum ble_cpu_clock_enable

{

   CPU_CLOCK_DISABLE          = 0x00,

   DEFAULT_CPU_CLOCK_ENABLE   = 0x01,

   POWERSAVE_CPU_CLOCK_ENABLE = 0x02,

};

typedef enum

{

    CPU_CLK_SPEED_24MHZ,

    CPU_CLK_SPEED_12MHZ,

    CPU_CLK_SPEED_8MHZ,

    CPU_CLK_SPEED_6MHZ,

    CPU_CLK_SPEED_4MHZ,

    CPU_CLK_SPEED_3MHZ,

    CPU_CLK_SPEED_2MHZ,

    CPU_CLK_SPEED_1MHZ

} CLOCK_SPEED;

In order to obtain lower power consumption.

How do I set the cpu speed in apps?

In the 1.x SDK using the 20732S, I found that even if I sent a fine timer rate at something quite high, it would only actually fire when the device was awake anyway - that is, the fine timer itself was not sufficient to wake up the device.

So for example, I could set the timer at 25ms rate, and a 500ms connection interval.  The timer would only fire when the device woke up to service the connection interval -- thus even though I asked for a 25ms timer it would in reality be more like 500ms.

As first I thought of this as a bug, but I worked around it and ultimately it turns out to be sort of handy because now I have a timer that fires fast, but only when the device is awake, thus not causing much additional overhead.  In fact it also represented a clever way to tell whether or not the device was awake, based on the timer latency.

Fast forward to the 20736S and SDK 2.0....

Now it appears the "bug" has been fixed.  When I set a timer of 25ms I get 25ms.

Is there any way to get something similar to the original functionality -- a timer that fires at a given rate but doesn't actually cause the system to wake up -- only fires if it is awake for some other reason?