BTStack on WICED 3.5.2 problems (solved)


#1

I’m trying to use BTstack in WICED 3.5.2

  1. I have cloned https://github.com/bluekitchen/btstack to WICED-3.5.2/libraries

  2. Changed branch to ble-api-cleanup

  3. executed /port/wiced/create_examples.py

  4. Now building ./make btstack.spp_and_le_counter-RB_DUO fails with
    No rule to make target 'libraries/btstack/port/wiced/../../../drivers/bluetooth/firmware/43438A1/bt_firmware_image.c', needed by 'build/btstack/spp_and_le_counter-RB_DUO/Modules/libraries/btstack/port/wiced/../../../drivers/bluetooth/firmware/43438A1/bt_firmware_image.o'. Stop. This can be fixed by adding $(BT_CHIP_XTAL_FREQUENCY) to libraries/btstack/port/wiced/wiced.mk so the last part looks like this:
    $(NAME)_SOURCES += \ main.c \ btstack_run_loop_wiced.c \ hci_transport_h4_wiced.c \ ../../chipset/bcm/btstack_chipset_bcm.c \ ../../../drivers/bluetooth/firmware/$(BT_CHIP)$(BT_CHIP_REVISION)/$(BT_CHIP_XTAL_FREQUENCY)/bt_firmware_image.c \

  5. Next problem is tools/ARM_GNU/bin/Linux64/arm-none-eabi-ld: cannot open map file build/btstack/spp_and_le_counter-RB_DUO/binary/btstack/spp_and_le_counter-RB_DUO.map: No such file or directory. I’m working around this by mkdir build/btstack/spp_and_le_counter-RB_DUO/binary/btstack/ and now the build completes.

  6. When I run it on the Duo I see the following:

Starting WICED v3.5.2
Platform RB_DUO initialised
Started ThreadX v5.6
Initialising NetX_Duo v5.7_sp2
Creating Packet pools
WWD SDIO interface initialised
WLAN MAC Address : E0:76:D0:37:83:19
WLAN Firmware : wl0: Nov 25 2015 12:57:14 version 7.45.45.1 (r602358) FWID 01-1920c040
BTstack on WICED
Broadcom init script BCM4343A1_001_002_009_0018_0000_Generic_UART_26MHz_wlbga_ref_hcd, len 17405
RFCOMM_REGISTER_SERVICE channel #1 mtu 65535 flow_control 0 credits 10
L2CAP_REGISTER_SERVICE psm 0x3 mtu 65535
L2CAP_REGISTER_SERVICE psm 0x1 mtu 65535
SDP service record size: 95
hci_power_control: 1, current mode 0
Broadcom init script BCM4343A1_001_002_009_0018_0000_Generic_UART_26MHz_wlbga_ref_hcd, len 17405
BTSTACK_EVENT_STATE 1
hci_initializing_run: substate 0
.
Resend HCI Reset
hci_initializing_run: substate 0

Resend HCI Reset
hci_initializing_run: substate 0

Resend HCI Reset
hci_initializing_run: substate 0

With HCI logging enabled:

EVT <= 60 01 01
hci_initializing_run: substate 0
CMD => 03 0C 00
.
EVT <= 6E 00
Resend HCI Reset
hci_initializing_run: substate 0
CMD => 03 0C 00

Other examples have the same problem. Any ideas?


#2

Hi. Last time I’ve tried with WICED 3.3.1. The fix with the BT_CHIP_XTAL_FREQUENCY most likely results from there. Please use master branch now. The ble-api-cleanup branch has solved it’s purpose and isn’t used anymore.

The log indicates that the Bluetooth chip isn’t responding, hard to guess what’s going on there.

I’ll give it a try on 3.5.2 soon. Stay tuned.


#3

Hi again. I’ve updated the BTstack develop branch to compile against the 3.5.2 SDK. Unfortunately, BTstack doesn’t get a response from the Broadcom Bluetooth chipset.

@redbear: Where’s the version of BTstack that’s used with the Arduino SDK? Does it use 3.3.1 or 3.5.2?

For now, you could use the 3.3.1 SDK with the ble-api-cleanup branch as it worked for me. You would also need the older version of RedBear’s SDK fix for 3.3.1 - there’s an 3.3.1 branch most likely for this.

I’ll try to figure out what changed between the SDKs.

Matthias


#4

Do you mean the WICED SDK version we building the libraries with? If so, 3.3.1 is used.

BTW, thank you so much for your support! :wink:


#5

No surprise for you, but I confirm it works with WICED 3.3.1 and BTstack ble-api-cleanup branch.


#6

Hi. Broadcom changed the function signature of platform_uart_receive_bytes without mentioning it anywhere and I’ve missed the compiler warning.

I’ve fixed it in the master branch. Please try again :slight_smile:

Thanks to RedBear for pointing out the change.


#7

With some small fixes to wiced.mk (see my pull request) it now works with WICED 3.5.2! :slight_smile: Thanks! I’ll try to update the README files as well.


#8

Thanks for the pull request. I added the 3.3.1 + 3.5.2 fix in the end and didn’t see the incorrect := assignment.