- 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.