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)?