[log] i'm presently interested in making muse-lsl work on my raspberry pi running into this: bleak.exc.BleakDBusError: [org.bluez.Error.NotReady] Resource Not Ready to try to troubleshoot it, i ran with some code of my own called 'pymuse' or 'sqrt(heartbrain)', a small test of accessing the device with different bluetooth backends. i used the same bleak backend. however, i am now running into the same error in the heartbrain code. so maybe it is a system thing.
to clarify, i had a run with the sqrt(heartbrain) code, that succeeded, at first. later runs failed.
normal approaches might include searching the web for similar issues, or restarting system services, or reloading kernel modules. there are also diagnostic bluetooth tools that can give information. one can also try with other backends. i already did a web search on this error. i'm not quite sure where the tab is at that regards it.
okay, i'm looking a little throug https://forums.raspberrypi.com/viewtopic.php?t=308954 which is now possible open in two tabs at once apparently gnome has a menu for toggling bluetooth. my menu says 'bluetooth off' and if i open it, it says 'turn off bluetooth' underneath it.
opened up system config. looks like bluetooth isn't turning on when enabled. solutiosn include: - debugging and fixing issue, my preference, takes too long to succeed at task though - purchasing bluetooth dongle, possibly more reliable, also takes too long - using different system - finding an existing 'bled' dongle. there's an old donge used in research communities that i have some of. not sure where they are. it's userspace, so the various projects have specific code to support it.
each of these approaches has a problem 1. debugging and fixing issue, my preference - likely takes too long to succeed at task before having amnesia without extra willpower 2. purchasing bluetooth dongle, possibly more reliable - also takes too long before having amnesia, without extra willpower 3. using different system - i'm not sure what other system to use. 4. finding an existing 'bled' dongle. - i'm not sure where these dongles are.
my phone had a vibration alarm going on, and i was confused because i thought i was experiencing a tactile hallucination, which parts of my brain often use to get my attention
i'm currently recovering from a previous use of extra willpower, so 1 and 2 look somewhat unideal. I have interest in pursuing #1 _without_ expecting success. this could help for years down the road. #3 and #4 are mostly engaging my difficulty going outside. i have another system, and i think i have 'bled' dongles, possibly outside. i'm not sure. i could also look other places for 'bled' dongles, but most of the places i would look are outside. so roughly it's a different kind of extra willpower.
i think i'll try to work on #1 a little bit since it's my preference kinda. i may not get anywhere.
i'm thinking that #1 would be aided if i had enough free disk space to build my kernel and system services from source. another blocker is bisecting between events that trigger or don't trigger the issue, which likely means rebooting the pi. it would be good to narrow things down in some way. there are also ideas of running things while the system is live, to try to get more information. it's unfortunate that that thread on the official forums had no official comment. it could make sense to work directly with a kernel module to learn more about the problem. it might be resolvable simply by reloading the module.
here's a line from the output of 'sudo lsmod' on this system: bluetooth 696320 45 btrtl,btqca,btsdio,btintel,hci_uart,btbcm,bnep,rfcomm the module 'bluetooth' is being used byb all the modules listed in the rightmost column, i think
some of the modules listed in that rightmost column are not visible elsewhere in the lsmod output
rerunning the command resolves this. terminal log exists, don't know if that will stay the case.
i cloned https://github.com/labapart/gattlib (or soemthing like that) and ran its python library through pymuse/sqrt(heartbrain) . it rose no errors but didn't find a device. the advantage of gattlib is it bypasses linux's dbus system (i think, might remember wrong)
actually it does raise an error part of output looks like this: Warning: gattlib has no way to enumerate devices that are already connected via b luetooth. Traceback (most recent call last): File "/home/ubuntu/src/pymuse/bt_gattlib.py", line 66, in start_scanning self._adapter.scan_enable(on_scan, 0) File "/home/ubuntu/.local/lib/python3.9/site-packages/gattlib/adapter.py", line 106, in scan_enable handle_return(ret) File "/home/ubuntu/.local/lib/python3.9/site-packages/gattlib/exception.py", li ne 60, in handle_return raise DBusError() gattlib.exception.DBusError
the bluez git source code is at https://git.kernel.org/pub/scm/bluetooth/bluez.git dbus is the proper way to engage bluez nowadays, it seems. but it sounds like there are example apps in the tree that don't use dbus.
bluez has a tool called 'btmgmt' that is in the tree but also generally installed, that appears to avoid dbus. $ ./btmgmt power on Set Powered for hci0 failed with status 0x03 (Failed) Meanwhile dmesg is scrolling these by. It's actually scrolling even without the btmgmt command: [25405.762943] Bluetooth: hci0: command 0x1001 tx timeout [25407.775009] Bluetooth: hci0: command 0x1009 tx timeout [25411.967140] Bluetooth: hci0: hardware error 0x00 [25413.983114] Bluetooth: hci0: command 0x1003 tx timeout [25415.999142] Bluetooth: hci0: command 0x1001 tx timeout [25418.015175] Bluetooth: hci0: command 0x1009 tx timeout [25422.207267] Bluetooth: hci0: hardware error 0x00 [25424.223265] Bluetooth: hci0: command 0x1003 tx timeout [25426.239302] Bluetooth: hci0: command 0x1001 tx timeout Some issue with hci0. However, the adapter information works fine: $ btmgmt info Index list with 1 item hci0: Primary controller addr version 9 manufacturer 305 class 0x000000 supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr le advertising secure-conn debug-keys privacy static-addr phy-configuration current settings: ssp br/edr le secure-conn name ubuntu short name
When I use rfkill to block hci0, the dmesg messages stop. But they resume when it is unblocked. Removing an associated kernel module isn't presently easy: $ sudo rmmod bluetooth rmmod: ERROR: Module bluetooth is in use by: btrtl btqca btsdio btintel hci_uart btbcm bnep rfcomm $ sudo rmmod btbcm rmmod: ERROR: Module btbcm is in use by: hci_uart $ sudo rmmod hci_uart rmmod: ERROR: Module hci_uart is in use Not sure what it means when it doesn't say what it's in use by, but presumably something userspace?
I found it in the /sys tree using `find /sys -name hci0`. In /sys I saw it uses the serial port /dev/ttyAMA0 Then I used fuser on /dev/ttyAMA0 to find this process: /usr/bin/hciattach /dev/serial1 bcm43xx 3000000 flow - I'm guessing the /dev/ttyAMA0 serial protocol will give me way more information on how the driver is behaving. There's likely some way to log the raw traffic. Unsure how difficult processing it would be.
seems fun to at least log the traffic somehow! humorously, some of the hciattach parameters this ubuntu raspi is using are undocumented. there's no bcm43xx or 3000000 baud rate listed in the man page. but the values are recognisable. i'm thinking it makes sense to log the traffic by altering the hciattach source. this way i also get some source code to think about implementing workarounds in and stuff.
hciattach is run by a systemd process called 'hciuart'. I tried starting with just restarting this service. It failed, this is the journalctl output: Mar 06 14:57:14 ubuntu systemd[1]: Starting Configure Bluetooth Modems connected by UART... Mar 06 14:57:24 ubuntu btuart[55797]: Initialization timed out. Mar 06 14:57:24 ubuntu btuart[55797]: bcm43xx_init Mar 06 14:57:24 ubuntu systemd[1]: hciuart.service: Control process exited, code=exited, status=1/FAILURE Mar 06 14:57:24 ubuntu systemd[1]: hciuart.service: Failed with result 'exit-code'. Mar 06 14:57:24 ubuntu systemd[1]: Failed to start Configure Bluetooth Modems connected by UART.
I shutdown the hciuart and bluetooth services, then rmmod'd these modules: hci_uart btrtl btqca btsdio btintel btbcm bnep rfcomm bluetooth then modprobed them again and started the services back up. Same result, no change.
/dev/ttyAMA0 doesn't go away when those things are rmmod'd # cat /sys/class/tty/ttyAMA0/device/uevent DRIVER=uart-pl011 OF_NAME=serial OF_FULLNAME=/soc/serial@7e201000 OF_COMPATIBLE_0=brcm,bcm2835-pl011 OF_COMPATIBLE_1=arm,pl011 OF_COMPATIBLE_2=arm,primecell OF_COMPATIBLE_N=3 OF_ALIAS_0=serial1 OF_ALIAS_1=uart0 AMBA_ID=00241011 MODALIAS=amba:d00241011 I'm not finding an 'amba' kernel module, maybe that means it's compiled in. This looks like it's the source code: https://github.com/torvalds/linux/blob/master/drivers/tty/serial/amba-pl011.... I found a quick summary on this page, which rehashes stuff from the linux tree: https://cateee.net/lkddb/web-lkddb/SERIAL_AMBA.html If the serial port is straight on the arm chip, which I guess makes sense, it seems unlikely that it would be a serial port issue. More likely the chip connected to the serial port, which would mean the problem would be resolvable inside hciuart. Part of me is considering trying to put an oscilloscope on the pins. I have a little cheap pocket oscilloscope. -- But most likely the problem here is going to be that the chip is in a nonresponsive state that is documented in its specs manual, and can be reset by providing some pattern to the port. This seems really doable now. But also labor intensive. I guess the chip it is is described by that bcm43xx string, but it might make sense to look up the specific model number.
These lines at the start of my dmesg roughly identify my system hardware and firmware: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083] [ 0.000000] Linux version 5.13.0-1017-raspi (buildd@bos02-arm64-010) (gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.37) #19-Ubuntu SMP PREEMPT Wed Feb 9 09:27:35 UTC 2022 (Ubuntu 5.13.0-1017.19-raspi 5.13.19) [ 0.000000] random: fast init done [ 0.000000] Machine model: Raspberry Pi 4 Model B Rev 1.2
The Pi 4 B hardware is quickly enumerated here: https://www.raspberrypi.com/products/raspberry-pi-4-model-b/specifications/ Broadcom BCM2711, Quad core Cortex-A72 (ARM v8) 64-bit SoC @ 1.5GHz I'm confused as to whether the bcm2711 is baked into the arm chip or not. Maybe it doesn't matter too much.
This PDF is only 166 pages long: https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf
.... and doesn't mention "bluetooth" anywhere. I'm hence confounded by the hciuart driver being specified as bcm... ah-ha! it's bcm43xx, not bcm27xx. separate chip.
note: raspis have an eeprom they run, at https://github.com/raspberrypi/rpi-eeprom/ . hobbyists considering pi security might leave this out. The hardware schematics and boot process documentation are at https://github.com/raspberrypi/documentation/tree/develop/documentation/asci...
- the schematics do not appear to label the chips - there is a documented led called 'BT_ON' that purportedly lights when bluetooth is powered. this string does not appear to be present in the raspi 4 schematics. It's strange I'm having trouble finding this. The raspberry pi 3 bluetooth chip is clearly documented at https://www.raspberrypi.org/products/raspberry-pi-3-model-b/ : BCM43438 wireless LAN and Bluetooth Low Energy (BLE) on board It's possible the pi 4 uses the same chip. It's a bcm43xx .
I found a photo of the board. It looks like the bluetooth chip is under some shielding, but the FCC ID is printed: https://fccid.io/2ABCB-RPI4B In the internal photos FCC document they remove the shielding, revealing the chip underneath. It's unlabeled: https://fccid.io/2ABCB-RPI4B/Internal-Photos/Internal-Photos-4325659.pdf . This document also hilights where the antenna is. This is a lot of pdf files to look at on my tiny raspi. This document: https://fccid.io/2ABCB-RPI4B/User-Manual/Installation-Guide-4325624.pdf says this:
The Raspberry Pi 4 Model B+ module has an IEEE 802.11b/g/n/ac 1x1 WLAN, Bluetooth 5 and Bluetooth LE module based on the Cypress 43455 chip.
It looks like any really useful up-to-date documents are likely to be from infineon.com nowadays. https://www.infineon.com/dgdl/Infineon-CYW43455_Single-Chip_5G_WiFi_IEEE_802...
Cypress is converting the acquired IoT part numbers from Broadcom to the Cypress part numbering scheme. Due to this conversion, there is no change in form, fit, or function as a result of offering the device with Cypress part number marking. The table provides Cypress ordering part number that matches an existing IoT part number.
BCM43455 CYW43455 BCM43455XKUBG CYW43455XKUBG BCM43455HKUBG CYW43455HKUBG BCM4329 CYW4329 BCM4330 CYW4330
So, a cypress 43455, is a bcm43455. A step up from the raspi 3's bcm43438.
It's notable that this chip does both wifi and bluetooth, so the fact that I'm on the internet shows the chip is powered and functioning (i'm on wifi).
- the chip performs either SPI or UART communication based on a jumper set during powerup, so if my internet is uninterrupted then it's still doing UART, and is likely hardwired to always do uart. [spi and uart are different serial protocols. the kernel driver is offering uart.] - there are separate pcm and i2s pins for transferring audio data; these are configured via uart - the uart auto-detects baud rates up to 4Mbps. the baud rate can also be configured via a command in the old baud - > The UART supports the Bluetooth 5.0 UART HCI specification: H4, a custom Extended H4, and H5. The default baud rate is 115.2 Kbaud. Further text:
The UART supports the 3-wire H5 UART transport, as described in the Bluetooth specification (Three-wire UART Transport Layer). Compared to H4, the H5 UART transport reduces the number of signal lines required by eliminating the CTS and RTS signals. The CYW43455 UART can perform XON/XOFF flow control and includes hardware support for the Serial Line Input Protocol (SLIP). It can also perform wake-on activity. For example, activity on the RX or CTS inputs can wake the chip from a sleep state.
I think it makes sense to observe the serial traffic in software now. It's behaving as if there's no reply at all, which implies the baud could be somehow wrong, I suppose. Not sure.
i'm kind of outdoors now, away from the raspi 4. I didn't find my bled112 dongles. here is a draft: diff --git a/tools/hciattach.c b/tools/hciattach.c index 276a4e56e..c5f3c7462 100644 --- a/tools/hciattach.c +++ b/tools/hciattach.c @@ -38,6 +38,30 @@ #include "hciattach.h" +void hex(int pfx, int fd, int buf, int len) { + while (len > 0) { + fprintf(stderr, "%s %d", pfx, fd); + for (int i = 0; i < len && i < 16; i ++) { + fprintf(stderr, " %02x", buf[i]); + } + fprintf(stderr, "\n") + len -= 16; + buf -= 16; + } +} + +int dbg_read(int fd, int buf, int len) { + int r = read(fd, buf, len); + hex("<", fd, buf, r); + return r; +} + +int dbg_write(int fd, int buf, int len) { + int r = write(fd, buf, len); + hex(">", fd, buf, r); + return r; +} + struct uart_t { char *type; int m_id; @@ -102,7 +126,7 @@ int read_hci_event(int fd, unsigned char* buf, int size) /* The first byte identifies the packet type. For HCI event packets, it * should be 0x04, so we read until we get to the 0x04. */ while (1) { - r = read(fd, buf, 1); + r = dbg_read(fd, buf, 1); if (r <= 0) return -1; if (buf[0] == 0x04) @@ -112,7 +136,7 @@ int read_hci_event(int fd, unsigned char* buf, int size) /* The next two bytes are the event code and parameter total length. */ while (count < 3) { - r = read(fd, buf + count, 3 - count); + r = dbg_read(fd, buf + count, 3 - count); if (r <= 0) return -1; count += r; @@ -125,7 +149,7 @@ int read_hci_event(int fd, unsigned char* buf, int size) remain = size - 3; while ((count - 3) < remain) { - r = read(fd, buf + count, remain - (count - 3)); + r = dbg_read(fd, buf + count, remain - (count - 3)); if (r <= 0) return -1; count += r; @@ -180,7 +204,7 @@ static int ericsson(int fd, struct uart_t *u, struct termios *ti) } /* Send initialization command */ - if (write(fd, cmd, 5) != 5) { + if (dbg_write(fd, cmd, 5) != 5) { perror("Failed to write init command"); return -1; } @@ -217,7 +241,7 @@ static int digi(int fd, struct uart_t *u, struct termios *ti) } /* Send initialization command */ - if (write(fd, cmd, 5) != 5) { + if (dbg_write(fd, cmd, 5) != 5) { perror("Failed to write init command"); return -1; } @@ -271,7 +295,7 @@ static int read_check(int fd, void *buf, int count) int res; do { - res = read(fd, buf, count); + res = dbg_read(fd, buf, count); if (res != -1) { buf += res; count -= res; @@ -297,7 +321,7 @@ static void bcsp_tshy_sig_alarm(int sig) if (retries < bcsp_max_retries) { retries++; - if (write(serial_fd, &bcsp_sync_pkt, 10) < 0) + if (dbg_write(serial_fd, &bcsp_sync_pkt, 10) < 0) return; alarm(1); return; @@ -315,7 +339,7 @@ static void bcsp_tconf_sig_alarm(int sig) if (retries < bcsp_max_retries){ retries++; - if (write(serial_fd, &bcsp_conf_pkt, 10) < 0) + if (dbg_write(serial_fd, &bcsp_conf_pkt, 10) < 0) return; alarm(1); return; @@ -393,7 +417,7 @@ static int bcsp(int fd, struct uart_t *u, struct termios *ti) } if (!memcmp(bcspp, bcspsync, 4)) { - if (write(fd, &bcsp_sync_resp_pkt,10) < 0) + if (dbg_write(fd, &bcsp_sync_resp_pkt,10) < 0) return -1; } else if (!memcmp(bcspp, bcspsyncresp, 4)) break; @@ -438,9 +462,9 @@ static int bcsp(int fd, struct uart_t *u, struct termios *ti) } if (!memcmp(bcspp, bcspsync, 4)) - len = write(fd, &bcsp_sync_resp_pkt, 10); + len = dbg_write(fd, &bcsp_sync_resp_pkt, 10); else if (!memcmp(bcspp, bcspconf, 4)) - len = write(fd, &bcsp_conf_resp_pkt, 10); + len = dbg_write(fd, &bcsp_conf_resp_pkt, 10); else if (!memcmp(bcspp, bcspconfresp, 4)) break; else @@ -508,7 +532,7 @@ static int csr(int fd, struct uart_t *u, struct termios *ti) /* Send command */ do { - if (write(fd, cmd, clen) != clen) { + if (dbg_write(fd, cmd, clen) != clen) { perror("Failed to write init command (GET_BUILD_ID)"); return -1; } @@ -552,7 +576,7 @@ static int csr(int fd, struct uart_t *u, struct termios *ti) #ifdef CSR_DEBUG /* Send command */ do { - if (write(fd, cmd, clen) != clen) { + if (dbg_write(fd, cmd, clen) != clen) { perror("Failed to write init command (GET_BUILD_ID)"); return -1; } @@ -618,7 +642,7 @@ static int csr(int fd, struct uart_t *u, struct termios *ti) #endif /* Send the command to set the CSR UART speed */ - if (write(fd, cmd, clen) != clen) { + if (dbg_write(fd, cmd, clen) != clen) { perror("Failed to write init command (SET_UART_SPEED)"); return -1; } @@ -673,7 +697,7 @@ static int swave(int fd, struct uart_t *u, struct termios *ti) } /* Send initialization command */ - if (write(fd, cmd, 10) != 10) { + if (dbg_write(fd, cmd, 10) != 10) { perror("Failed to write init command"); return -1; } @@ -685,7 +709,7 @@ static int swave(int fd, struct uart_t *u, struct termios *ti) nanosleep(&tm, NULL); - r = read(fd, rsp, sizeof(rsp)); + r = dbg_read(fd, rsp, sizeof(rsp)); if (r > 0) { // guess it's okay, but we should parse the reply. But since // I don't react on an error anyway ... todo @@ -714,7 +738,7 @@ static int swave(int fd, struct uart_t *u, struct termios *ti) cmd[3] = 0x00; /* Send reset command */ - if (write(fd, cmd, 4) != 4) { + if (dbg_write(fd, cmd, 4) != 4) { perror("Can't write Silicon Wave reset cmd."); return -1; } @@ -779,7 +803,7 @@ static int st(int fd, struct uart_t *u, struct termios *ti) } /* Send initialization command */ - if (write(fd, cmd, 5) != 5) { + if (dbg_write(fd, cmd, 5) != 5) { perror("Failed to write init command"); return -1; } @@ -855,7 +879,7 @@ static int bcm2035(int fd, struct uart_t *u, struct termios *ti) cmd[3] = 0x00; /* Send command */ - if (write(fd, cmd, 4) != 4) { + if (dbg_write(fd, cmd, 4) != 4) { fprintf(stderr, "Failed to write reset command\n"); return -1; } @@ -877,7 +901,7 @@ static int bcm2035(int fd, struct uart_t *u, struct termios *ti) str2ba(u->bdaddr, (bdaddr_t *) (cmd + 4)); /* Send command */ - if (write(fd, cmd, 10) != 10) { + if (dbg_write(fd, cmd, 10) != 10) { fprintf(stderr, "Failed to write BD_ADDR command\n"); return -1; } @@ -898,7 +922,7 @@ static int bcm2035(int fd, struct uart_t *u, struct termios *ti) cmd[3] = 0x00; /* Send command */ - if (write(fd, cmd, 4) != 4) { + if (dbg_write(fd, cmd, 4) != 4) { fprintf(stderr, "Failed to write \"read local version\" " "command\n"); return -1; @@ -919,7 +943,7 @@ static int bcm2035(int fd, struct uart_t *u, struct termios *ti) cmd[3] = 0x00; /* Send command */ - if (write(fd, cmd, 4) != 4) { + if (dbg_write(fd, cmd, 4) != 4) { fprintf(stderr, "Failed to write \"read local supported " "commands\" command\n"); return -1; @@ -965,7 +989,7 @@ static int bcm2035(int fd, struct uart_t *u, struct termios *ti) cmd[4], cmd[5]); /* Send command */ - if (write(fd, cmd, 6) != 6) { + if (dbg_write(fd, cmd, 6) != 6) { fprintf(stderr, "Failed to write \"set baud rate\" command\n"); return -1; }
back indoors, and noting that hciattach is guarded by an automake flag called DEPRECATED
this describes similar issues, although they might be slightly different: https://github.com/denysvitali/linux-on-pixel-c/issues/10 it looks like a lot of patches have been made to address issues like these, including to the kernel. it's a little daunting that part of the fix involved firmware. i do have local firmware,.but with a different naming convention and generally suffixed with 'sdio' which i'm unsure if is okay. i'm wondering if these patches may have likely made it to raspbian, the official operating system, but not ubuntu arm 64, which i am running.
two ways to connect hci to tty, both fail on my ubuntu raspi 4 atm: btattach -B /dev/ttyAMA0 -P bcm -S 3000000 hciattach /dev/ttyAMA0 bcm43xx 3000000 flow -
goal: add debugging output to anything that uses a file descriptor this could add information regarding serial specifics
uncertain $ tools/hciattach /dev/ttyAMA0 bcm43xx 3000000 flow - open '/dev/ttyAMA0', 258 -> 3 tcflush 3 -> 2 tcattr< 3 00 00 00 00 00 00 00 00 b2 18 00 80 00 00 00 00 tcattr< 3 18 77 11 ea 03 00 00 00 00 00 00 00 00 00 00 00 tcattr< 3 b8 71 61 e1 ff ff 00 00 20 70 61 e1 ff ff 00 00 tcattr< 3 00 00 00 00 00 00 00 00 58 56 15 ea tcattr> 3 00 00 00 00 00 00 00 00 b2 18 00 80 00 00 00 00 tcattr> 3 18 77 11 ea 03 00 00 00 00 00 00 00 00 00 00 00 tcattr> 3 b8 71 61 e1 ff ff 00 00 20 70 61 e1 ff ff 00 00 tcattr> 3 00 00 00 00 00 00 00 00 58 56 15 ea 0 -> 0 tcattr> 3 00 00 00 00 00 00 00 00 b2 18 00 80 00 00 00 00 tcattr> 3 18 77 11 ea 03 00 00 00 00 00 00 00 00 00 00 00 tcattr> 3 b8 71 61 e1 ff ff 00 00 20 70 61 e1 ff ff 00 00 tcattr> 3 00 00 00 00 00 00 00 00 58 56 15 ea 0 -> 0 tcflush 3 -> 2 bcm43xx_init
3 01 03 0c 00 Initialization timed out.
participants (1)
-
Undiscussed Horrific Abuse, One Victim of Many