evaluating wl18xx support - can't get demos working.

[mjhammel]

Describe the bug

Built posix-h4 and daemon with/h4. Tested BTdaemon and a2dp_source_demo on x86_64 target platform. I expect the latter to show up on my phone for testing but it doesn't. Neither does BTdaemon but I wasn't sure what should happen with this as it appears that port is not in the documentation. I know I need to enable a gpio pin plus execute an hci command to map I2S pins to HCI as this is how I got bluez working previously. I've done this (leaving hciattach running) in a shell script but still no sign of a2dp_source_demo on my phone. It's unclear what I need to do now.

To Reproduce

Steps to reproduce the behavior:

1. Build posix-h4 port, modifying CORE to include TIInit_11.8.32.c.
2. Run example 'a2dp_source_demo'
3. Attempt to connect from Android phone.

Note that the default btstack_config.h for posix-h4 does not specify any chips. Not sure if it's supposed to.

Expected behavior

The bstack demo should show up as a new pairable device in Settings->Connected Devices->Pair New Device on my phone.

HCI Packet Logs Note: I don't know why the logs have all these special characters in them.

$ tail -f /tmp/hci_dump.pklg <fy�����le_device_db_tlv.c.164: btstack_tlv not initialized?fy�����l2cap.c.4991: L2CAP_REGISTER_SERVICE psm 0x19 mtu 1017@fy�����l2cap.c.4991: L2CAP_REGISTER_SERVICE psm 0x17 mtu 65535?fy����l2cap.c.4991: L2CAP_REGISTER_SERVICE psm 0x1 mtu 655359fy���5�hci.c.5497: hci_power_control: 1, current mode 09fy���h�btstack_uart_posix.c.170: h4_set_baudrate 1152006fy��<~�btstack_uart_posix.c.361: Open tty /dev/ttyS2*fy��<��hci.c.8103: BTSTACK_EVENT_STATE 1 fy��<� Jfy��<��btstack_run_loop_posix.c.170: POSIX run loop with monotonic clock%fy�� J��hci.c.1826: Resend HCI Reset

Environment: (please complete the following information):

• Current BTstack branch: Tag 1.6.1
• Bluetooth Controller: TI wl18xx - specifically, TI WL1830MOD
• Remote device: Moto G Play phone running Android v12.

Additional context I'm evaluating (against a number of alternatives to bluez) the work required to integrate the btstack build into our custom build system to generate a shared library for use by app devs. I see an example of this in the daemon, which appears to support H4 but I'm not clear if the shared library includes the same source as the posix-h4 demo. Before I do this I need to show that at least one demo app works with our BT hardware and can be seen by a remote device.

[mringwal]

Hi MIchael. The hci_dump.pklg is a binary file. Could you zip it and upload it to this issue?

From the text snippets (which are stack debug output), it looks like the WL18xx never answered to the first HCI Reset command.

For posix-h4, please make sure bluez does not access /dev/tty of the WL18xx, you have permissions to open the port, and reset the WL18xx before starting an example, e.g. a2dp_sink_demo (if you want to stream music from your mobile phone to BTstack).

[mjhammel]

Sure thing. I've attached the logs here as gzip. 001 is a a2dp-source-demo session. 002 is an a2dp-sink-demo session.

Not completely sure how to reset the WL18xx. I run a setup script that disables and then re-enables the associated gpio line, then attaches with hciattach to use hcitool to send vendor commands to map the I2S lines to HCI. I then kill hciattach. If there is a better way to reset (I'm betting there is), let me know. Thanks.

001-hci_dump.pklg.gz 002-hci_dump.pklg.gz

[mringwal]

For completeness: could you a) post the setup script + the hciattach command line, and b) try BTstack after powering up the WL18xx without any setup or hciattach.

A first step would be to let BTstack start normally and then tweak what's necessary.

BTstack can/will configure SCO-over-HCI by itself.

[mjhammel]

Log after reboot, without my setup:
003-hci_dump.pklg.gz

Setup script, which includes the hciattach command. btsetup.sh.gz

For completeness, here are the hci commands in the script.

• hciattach "/dev/${PORT}" texas 115200
• hcitool cmd 0x3f 0x0210 0x01 0x78 0xff 0x01 0xff

[mringwal]

I see. ok, in this case, please only run the part in the setup script that enables the GPIO pin, which is probably the Bluetooth nSHUTD line, then pull that to GND (= Shutdown), wait 500 ms, and then up (= working) again to power cycle it. Then, start BTstack as before.

[mjhammel]

I enabled the gpio pin only. Looks like progress:

$ ./a2dp_sink_demo -u /dev/ttyS2 Packet Log: /tmp/hci_dump.pklg H4 device: /dev/ttyS2 No audio playback. Audio will be stored to 'a2dp_sink_demo.wav' file. Starting BTstack ... Local version information:

• HCI Version 0x0006
• HCI Revision 0x0000
• LMP Version 0x0006
• LMP Subversion 0xac20
• Manufacturer 0x000d Texas Instruments - CC256x compatible chipset. Using 921600 baud. eHCILL disable. Local name: BTstack up and running on 38:AB:41:F3:4C:3F. TLV path: /tmp/btstack_38-AB-41-F3-4C-3F.tlv

But I still don't see the target platform from my phone. What device name should show up? Local name is blank in that output - maybe I need to set it somehow?

[mringwal]

Ok, that's a start. Please post hci_dump.pklg again. BTstack needs to load the InitScript for the WL18xx - something the hciattach usually does.

[mringwal]

Local name blank is fine, TI's Controllers doesn't have one after startup. Broadcom/Infineon/Cypress indicate the Controller name here.

[mjhammel]

Ah. Okay, so here's the updated log. 004-hci_dump.pklg.gz

[mringwal]

Looks good. It detect the TI variant, increases the baud rate, loads the init script and starts up the stack. Then, the demo takes over and makes the device discoverable. All as exptected now.

Could you try to run the gap_inquiry + gap_le_advertisement examples plus post hci_dumps for it? They do a Classic resp. Classic discovery.

[mjhammel]

Here are the logs: 005-hci_dump.plkg.gz 006-hci_dump.pklg.gz 007-hci_dump.pklg.gz 008-hci_dump.pklg.gz

005 was without rebooting my target - I had been running tests on other hardware so don't know if this is valid or not.

006 is just gap_inquiry. This one printed to the console:

$ ./gap_inquiry -u /dev/ttyS2 Packet Log: /tmp/hci_dump.pklg H4 device: /dev/ttyS2 Local version information:

• HCI Version 0x0006
• HCI Revision 0x0000
• LMP Version 0x0006
• LMP Subversion 0xac20
• Manufacturer 0x000d Texas Instruments - CC256x compatible chipset. Using 921600 baud. eHCILL disable. Local name: BTstack up and running on 38:AB:41:F3:4C:3F. TLV path: /tmp/btstack_38-AB-41-F3-4C-3F.tlv Starting inquiry scan.. Starting inquiry scan.. Starting inquiry scan.. Starting inquiry scan.. Starting inquiry scan.. Starting inquiry scan.. Starting inquiry scan.. Starting inquiry scan.. Starting inquiry scan.. Starting inquiry scan.. Starting inquiry scan.. Starting inquiry scan.. Starting inquiry scan.. ^CCTRL-C - SIGINT received, shutting down..

007 is gap_le_advertisements without resetting the gpio line. It hung with the following.

$ ./gap_le_advertisements -u /dev/ttyS2 Packet Log: /tmp/hci_dump.pklg H4 device: /dev/ttyS2 ^CCTRL-C - SIGINT received, shutting down..

It was killed when I reset the gpio line.

008 is also gap_le_advertisements after resetting the gpio line. This one exited on its own with the following.

$ ./gap_le_advertisements -u /dev/ttyS2 Packet Log: /tmp/hci_dump.pklg H4 device: /dev/ttyS2 gap_le_advertisements: ../../platform/posix/btstack_uart_posix.c:396: btstack_uart_posix_receive_block: Assertion `btstack_uart_block_read_bytes_len == 0' failed. Aborted

Is there a tool I should use to examine these logs myself? I imagine we'd want to do that in our app eventually, assuming we use btstack logging mechanisms.

[mringwal]

Thanks for the logs. The logs are in Apple's PacketLogger format, which you can use to open it if you're on a Mac. Otherwise, you can view the logs with Wirehshark on all platforms. I use both since both tools have their strengths and weaknesses.

Logs 5,7,8, hang in the "Send Reset wait for Command Complete". The WL18xx start at 115200, then BTstack sets the baudrate to 921600 and uploades the InitScript (patch file). To start it again, you'll need to reset Bluetooth before BTstack can talk to it again. If you like, you can repeat the gap_le_advertisements after resetting the WL18xx.

Log 6: all good, but there's not a single device in your environment, which is not wrong per se. You may make a device discoverable, e.g. your phone by going to the Bluetooth settings.

In most environments there are a number of LE device around, so the gap_le_advertisement might show them.

Anyway, it's not clear yet, if the Controller is properly initialized.

As another test, you could power cycle and run hciattach as before, then just quit it. The WL18xx should be ready now and you can start one of the demos. The question here is what baud rate is set by hciattach. 115200 is the default, but that's too slow for audio (e.g. A2DP). Other guesses would be 921600, 200000 and 300000. If BTstack starts up and the radio works, we'll need to figure out what InitScript to use.

We do have a WL18xx dev kit somewhere for comparison that I can dig out if these steps won't get it working for you.

[mjhammel]

First - thanks for your help on this. I told the tech lead today that we should just go with btstack since we knew there was limited supported expected but you've been so helpful anyway. It's more responsive than I've had with lots of places these days.

Log 6 probably should have seen something if the initialization went okay. My phone sees 4 or 5 near by devices. Also, while I can't prove it (re: can't remember), I think the phone was in pair mode during those tests. But I'll try again to be certain.

I'll try the bluetooth reset (which I assume means the wl18xx reset using the gpio pin) and see what happens. FWIW, this is what I see when running hciattach - looks like it sets it to 300000. My script doesn't do that, so it must be hciattach.

$ ./btsetup.sh -g 887 -R -m resetGPIO called. ---- Disabling GPIO for BT. enableGPIO called. ---- Attaching serial port (UART) to BT. Found a Texas Instruments' chip! Firmware file : /lib/firmware/ti-connectivity/TIInit_11.8.32.bts Loaded BTS script version 1 texas: changing baud rate to 3000000, flow control to 1 Device setup complete ---- Mapping I2S pins to HCI pins. < HCI Command: ogf 0x3f, ocf 0x0210, plen 5 01 78 FF 01 FF

HCI Event: 0x0e plen 6 01 10 FE 00 78 04 Cleanup called.

If I run this, then run gap_le_advertisements it just hangs. If I then just reset/re-enable on the gpio but without hciattach doing its thing, then it runs but doesn't see anything.

[mringwal]

After hciattach sets the baudrate to 3 mbps, you should be able to start any BTstack demo after:

• set main baudrate to 300000 (instead of 11520) in hci_transport_config_uart_t config port/posix-h4/main.c
• disable TI support by commenting the code after case BLUETOOTH_COMPANY_ID_TEXAS_INSTRUMENTS_INC in main.c

I'll try to find the WL18xx board, but the above might work for you, too.

[mringwal]

Btw. where did you get TIInit_11.8.32.c from? We host a number of TI InitScripts that are downloaded during build. For the WL18xx, you would need to specify TIInit_11.8.32_4.8.c in the CMakeLists.txt.

[mringwal]

Also, thanks for your feedback and recommendation. For business topics, please get in contact with us at contact@bluekitchen-gmbh.com

[mjhammel]

I made the mods and rebuilt, copied binaries to target. I ran my script that does the hciattach to set baud rate (tested with and without mapping the I2S pins to HCI pins and with/without killing hciattach) then ran gap_le_advertisements -u /dev/ttyS2. Nothing happens. Logs says it failed HCI_INIT. I've attached log and the patch I apply to the code.

The Makefile in posix-h4 references TIInit_11.8.32.c. I mod'd it to _4.8 in the supplied patch. I'm using GNU make, not cmake. I'm old school, what can I say. :-)

hci_dump.pklg.gz posix-h4.patch.gz

[mringwal]

Hi @mjhammel Ok, found the setup. It's actually this one:

After figuring out how to connect an 3.3V FTDI adapter and selecting TIInit_11.8.32_4.8.c, I was able to startup the gap_le_advertisements demo and got normal results.

hci_dump_gap_le_advertisements_wl1835.pklg.zip

As that's working, I would suggest to stick with BTstack only. My guess is that the GPIO in your platform is connected to the nShutdown pin of the WL18xx. To reset the Controller (the WL18xx), you configure the GPIO as output, then set it to 0 (to power off), wait e.g. 500 ms, then set it to 1 (to power on). After that, any of our examples should work out-of-the box after selecting the TIInit_11.8.32_4.8.c init script. Please try this one more time (and send logs).

Did this setup work with BlueZ before? The main difference should/could be the init script. Our conversion script adds a few commands to the init script provided by TI to configure the power levels. See btstack/chipset/convert_bts_initscripts.py. You could comment all calls to append or modify all append_ functions to just return 0.

Are there any differences between our 1835MOD on a dev kit and yours?

[mjhammel]

The GPIO pin is attached to BT_EN in the schematic, which at least sounds like nShutdown. I adjusted my setup script to set the pin to 0, hold for 0.5 seconds (also tried with 1s) and then set the pin to 1. I then ran gap_le_advertisements, but no luck. Logs say it can't set the baud rate. Log is attached.

hci_dump.pklg.gz

I verified I built with TIInit_11.8.32_4.8.c (the BTS was downloaded and converted to C and there is an .o in the build tree).

Once I found I had to map I2S to HCI I was able to get BlueZ to scan and connect to my phone. I was also able to route audio through it. I thought our chip was an 1830MOD but the schematic says 1831MOD, so I'm not sure which it is yet. But it's not an 1835 so it's probably different than your dev kit in some respects. I don't have the dev kit - they just give me the DVT boards from the manufacturer and I have to get Linux and the rootfs up and running. The driver is the stock kernel wl18xx driver(s) from 5.15 ported to allow use on x86 (instead of DTS), which is done by coding in the GPIO config into the wlcore_probe_of() function. However, we used TIInit_11.8.32.bts (saved to /lib/firmware/ti-connectivity) along with wl18xx-fw-4.bin.

I'll give the convert scripts a look and try your suggestion.

[mjhammel]

Quick note: I don't see the mapping of I2S to HCI pins sequence in the convert script. Wouldn't that need to be added? There is an I2S codec reference in the generated .c, but no reference to I2S in the convert script nor do I see the hex sequence for the command in either file. Just wondering if that should be added manually. Not completely sure how to do that yet, but still digging.

[mjhammel]

I found one problem. I put "300000" instead of "3000000" (thous vs mil) so the uart.c wasn't able to set the baud rate. Doh. Anyway, I fixed that. It looks better, but still nothing happens.

hci_dump.pklg.gz

Now I'll go and retry updating the convert script.

[mringwal]

After the power cycle, the controller starts up at 115200. Please revert posix-h4/main.c to that value. (The 3 mbps was an idea to take over after hciattach did load the initscript and has configured the controller for 3 mbps. If we start after reset, it's 115200 and BTstack updates the baud rate, in the current code to 921600 to be on the safe side with various UART drivers).

BTstack can route SCO over HCI, which is used for HFP and HSP only, during startup if ENABLE_SCO_OVER_HCI is defined. This is sent by btstack_chipset_cc256x.c, line 312 and later.

How SCO is routed does not have an obvious impact on general radio functionality.

[mjhammel]

Okay, much better. I reverted those main.c changes (baud change, and disabling the TI stuff in that case statement). Now, after I reset the chip, it does this:

$ ./gap_le_advertisements -u /dev/ttyS2 Packet Log: /tmp/hci_dump.pklg H4 device: /dev/ttyS2 Local version information:

• HCI Version 0x0006
• HCI Revision 0x0000
• LMP Version 0x0006
• LMP Subversion 0xac20
• Manufacturer 0x000d Texas Instruments - CC256x compatible chipset. Using 921600 baud. eHCILL disable. Local name: BTstack up and running on 38:AB:41:F3:4C:3F. TLV path: /tmp/btstack_38-AB-41-F3-4C-3F.tlv

But then it just sits there. I believe this should show what devices it sees, and there are devices it should see including my phone. Log shows much more activity but seems stuck in the scan.

hci_dump.pklg.gz

[mringwal]

TI uses the LMP Subversion to identify the different Bluetooth Controllers (e.g. there are 3 different versions of the CC256x) and their loaded InitScript. You get the same LMP Subversion as me and I was under the impression that the main difference in the WL-18xx Controllers is their Wifi functionality. Nevertheless, your device does not see advertisements.

I'm irritated that it doesn't work as we should have the same Bluetooth Controller (more or less).

Can you share the .bts that you've used with BlueZ here? Just to confirm: with this .bts file + hciattach + BlueZ, you have are able to use the WL18xx for Bluetooth (resp. it's working and you are considering replacing BlueZ with BTstack)?

[mjhammel]

Sorry for the late response - I was on vacation last week.

The BTS I use is: TIInit_11.8.32.bts. I had started with a much different (and probably very wrong) BTS file and no scans worked, but when I switched to this BTS the scans started working. The full script I use for testing is bt.sh.gz.

This .bts work with hciattach as long as I route the I2S pins to HCI pins after using hciattach to attach to the serial port. I can then use hcitool to scan for a named device and bluetoothctl to manage BT settings (power on, discoverable on, pairable on). I've been able to test A2DP (connected Jitsi conference on my phone and recorded audio via bt on the target platform).

We're looking at btstack to replace Bluez, specifically for the SIG qualification.

[mringwal]

No problem. Let's dig deeper now that you're refreshed :)

Thanks the BTS file. If you look at it with a hex editor, it's a) for the same device, b) much older.

To reduce the number of differences between our setups, I'd suggest you try the latest BTS from TI with your BlueZ setup and check if Scanning and e.g. A2DP is working. (Let's ignore HFP for now as we need to check the SCO routing).

The general idea would be that a device should behave in a similar way if the same data is sent to it.

[mjhammel]

Is 11.8.32 the latest or do you have another link I can use for that?

[mringwal]

The last one I have is: https://bluekitchen-gmbh.com/files/ti/service-packs/TIInit_11.8.32_4.8.bts We host versioned copies of the various init scripts for easier integration with BTstack.

[mjhammel]

I was able to test both the 11.8.32 that we were using and the 11.8.32_4.8 from your archive. Both versions worked with BlueZ to allow a pair and connection to my Moto G Android 12 mobile phone. and I was able to do A2DP with the target as the sink and my phone as the source. I played both music and videos on the phone and recorded the audio on the target. However, your version had blotchy (re: skipped bits) audio while the one we use had no noticable audio problems.

[mjhammel]

Also, I had to add an antenna (I had switched test boards for an unrelated reason) to retest with BlueZ so I decided to retry btstack with the antenna too. I got the following using the version of BTS you pointed me to (11.8.32_4.8):

$ ./gap_le_advertisements -u /dev/ttyS2 Packet Log: /tmp/hci_dump.pklg H4 device: /dev/ttyS2 Local version information:

• HCI Version 0x000a
• HCI Revision 0x0000
• LMP Version 0x000a
• LMP Subversion 0xac14
• Manufacturer 0x000d Texas Instruments - CC256x compatible chipset. Error: LMP Subversion does not match initscript! Your initscripts is for a newer chipset Please update Makefile to include the appropriate bluetooth_init_cc256???.c file

I was not able to reproduce this state, unfortunately. And I was not able to get btstack tools to do anything new with either BTS file using the antenna.

[mringwal]

Thanks for the testing. The version you've pointed to had a baud rate change command at the end of the file while the 11.8.32_4.8 version does not have it. This would explain the difference. Could you check/post the output from hci attach to see if that's the case?

Anyway, that's quite confusing. When using 11.8.32_4.8:

• BTstack works fine on my hardware
• BlueZ works fine on your hardware
• BTstack does not work on your hardware

Btw. not having a working antenna would be one explanation for not receiving advertisements, but it does not explain why it should work with BlueZ but not with BTstack.

I didn't see any code w.r.t. antenna configuration in the hciattach tool. Also, when you're running the same code as me with the same hardware, it should also work.

I can think of two paths forward: a) compare the HCI logs on startup and look for differences between Bluez/hciattach and BTstack using the same init script b) re-try to let hciattach download the init scipt and then try BTstack without support for init script upload

Btw. I assume you already have devices out in the field and/or you've decided to use the WL18xx and switching to a different Bluetooth/Wifi Controller is not an option.

HCI Log Compare

As far as I know, you can hci_dump on linux to get hci traces, but I'd rather not expect this to work for the init stage when hciattach runs. Some info here: https://hackaday.io/project/170365-blueretro/log/178249-learning-bluetooth-classic-bredr-with-hci-traces

If you have access to the UART itself, you could try our scripts to convert Salea Logic traces into hci_dump.pklg files. https://github.com/bluekitchen/bluetooth-logger/tree/master/saleae-logic2-uart

BTstack after HCI Attach

Please change the initial baudrate from 115200 to 300000 and comment the complete BLUETOOTH_COMPANY_ID_TEXAS_INSTRUMENTS_INC in local_version_information_handler(..) of port/posix-h4/main.c. Then, use your script to reset (power cycle) the controller, run it & hci attach. Then, run e.g. gap_le_advertisement.

Please send HCI logs for both endeavours.

[mjhammel]

This is hciattach with our default BTS.

$ hciattach "/dev/ttyS2" texas 115200 Found a Texas Instruments' chip! Firmware file : /lib/firmware/ti-connectivity/TIInit_11.8.32.bts Loaded BTS script version 1 texas: changing baud rate to 3000000, flow control to 1 Device setup complete

This is hciattach using your BTS.

$ hciattach "/dev/ttyS2" texas 115200 Found a Texas Instruments' chip! Firmware file : /lib/firmware/ti-connectivity/TIInit_11.8.32.bts Loaded BTS script version 1 Initialization timed out.

Although the "Firmware file" line says TIInit_11.8.32.bts, it's actually your version copied to that filename as that's what hciattach seems to want. I can't remember if I told it that with the build or it just knows it somehow.

re: devices in the field - this is early development but the board design is set, so we can't change the chip. There are not any devices in the field yet. I checked today and I have about 2-3 months to get the OS layer operational before I have to hand this to the apps devs to integrate BT into user space. With your help I feel confident we can do that.

I'll check out the hackaday hci trace article (that's a good site for lots of stuff - I'm reading their USB-C articles right now) and your uart scripts today. And I'll mod the main.c as requested and retry with the mixed toolset to see what happens. I'll post when I have results.

[mringwal]

Thanks for the hciattach logs. In your old BTS file, the baud rate changes to 3000000, which confirms that it uses 115200 with the newer BTS file. If needed, the baud rate change command could be added to the newer file.

For the test with running BTstack after hciattach: please keep in mind to set the baud rate correctly depending on the used OTS file. For the "old" one, please use 3000000. For the new/4.8, you can keep 115200 baud (and only have the 'comment TI specific code').

Let's see if that gets it working.

[mjhammel]

I'm back - they pulled me away to do USB stuff for awhile. But I think I cleared that up for now.j

I built port/posix-h4/main.c with the 115200 setting left in place, but #if'd out the case for BLUETOOTH_COMPANY_ID_TEXAS_INSTRUMENTS_INC (not the case, but the block it wrapped). Then I simply reset the GPIO line and run btstack commands using your BTS file. This appears to be working now.

$ ./btstack-115/usr/bin/gap_inquiry -u /dev/ttyS2 Packet Log: /tmp/hci_dump.pklg H4 device: /dev/ttyS2 Local version information:

• HCI Version 0x0006
• HCI Revision 0x0000
• LMP Version 0x0006
• LMP Subversion 0xac20
• Manufacturer 0x000d Texas Instruments - CC256x compatible chipset. Using 921600 baud. eHCILL disable. Local name: mdcBTstack up and running on 38:AB:41:F3:4C:3F. TLV path: /tmp/btstack_38-AB-41-F3-4C-3F.tlv Starting inquiry scan.. Device found: B0:4A:B4:D3:E3:53 with COD: 0x5a020c, pageScan 1, clock offset 0x3056, rssi -42 dBm, name 'hubble'

Device found: F4:4E:FD:37:F2:BF with COD: 0x240404, pageScan 1, clock offset 0x6ceb, rssi -70 dBm Device found: 00:06:66:87:FF:DE with COD: 0x240704, pageScan 2, clock offset 0x54dc, rssi -76 dBm, name 'Maker-FFDE' Get remote name of F4:4E:FD:37:F2:BF... Name: 'NS-SBAR21F20SW' Starting inquiry scan.. Starting inquiry scan.. Starting inquiry scan..

The scan is seeing local devices. My phone is "hubble". This seems very reproducable too. Not completely sure what I was doing wrong before, but this is nice to see. Do you have any other tests I could/should run? An example session I could run through to demonstrate to my team that it's working would be useful. For example, can I connect to my phone and play audio from there and record on the target that is running btstack? Does btstack provide an alsa device I can record from? After that, I could use some advice on how to train app devs on building an application with btstack. This will be very new to them.

[mringwal]

Looks good. According to this, the WL183x was configured at 115200 and BTstack did increase baud rate to 921600. In this case, you're all set.

Testing. A good test app is "gatt_counter", which implements a BLE Peripheral. You can connect from a smartphone using e.g. LightBlue or nRF Toolbox, browse the GATT Services and enable Notifications on one of the Characteristics.

You can run hfp_hf_demo, which implements a Handsfree-Unit. If you have PortAudio installed, audio might even work. You can select 'SINE' in example/sco_demo_util.c instead of live audio. Or, you can find the BD ADDR of a Bluetooth speaker/headset, set it in the code of a2dp_source_demo and run that. It will play a mod song on the speaker.

[mjhammel]

One last question: the BTS files you host are just more recent releases from TI, correct? My team lead was concerned about the origin of that file since the BTS files are what qualify the hardware via TI.

[mringwal]

The BTS files are unmodified versions from TI as TI does/did not provide a simple way to automatically download a specific version via URL. We did actual ask a long time ago if we're allowed to host them.

Our BTS to C array makes small modifications to set the power vector, enable eHCILL, and control the baud rate, which is documented in the Python code. For issues with the stack itself, this issue tracker is fine. For project/business support, please contact us via contact@bluekitchen-gmbh.com.