Update: RFCOMM negotiation works now – connecting to the serial TTY device enables use of one of the Arduino Due UARTs. You can send short strings across the Bluetooth SPP link. The hexadecimal dump below was apparently a Bluetooth dongle hardware error code, one byte “0x37” (0x10 0x01 0x37). Documentation from CSR (look for the document CS-227432-SP-3-BCCMD-HQ, by searching for “HQ Commands”) told me this was a hardware fault code with a funny name:
FAULT_ALREADY_BAGSIED: Two subsystems are attempting to use the same .
The same what? The PDF contains exactly that text, “… the same .” Nuts. The documentation was leading me nowhere, but clearly the dongle was receiving command data I was sending to it, and going into fault condition as a result.
It turned out that I was sending an incomplete RFCOMM packet – I forgot to include the HCI handle for the existing ACL connection in the command I was sending. Aargh…!
So, it works now, after a fashion. I’m able to connect to the UART to send very short strings. Trying to send anything longer in either direction will crash the dongle HCI stack, which says there’s still something wrong with the code. Get the updated code here, as well as the driver sketch here.
Some good news: The Atmel Software Framework 3.12 allows interrupt-driven reads and writes from any of the Bluetooth dongle pipes – control, event, and bulk I/O. This is good. Continue reading “Arduino Bluetooth Blues”