From: Steven Saunderson <[email protected]> Sent: Tuesday, 24 February 2015, 10:28 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth Today I've tested asserting and negating RTS at various times. Host RTS must be asserted at the end of the reset pulse and for 30ms after to get the device to assert its RTS (our CTS). Since I check for CTS before sending this causes the program to time out.
The timing is good to know. Does it still work if you wait 10ms after the end of the reset pulse and then assert RTS for 20ms? If it does then it suggests the controller needs a few millisecond to re-initialise, the manual says 4.2ms of sleep occurs during initialisation, and then it needs a sufficiently long pulse on its CTS as zero (host RTS asserted) for it to recognise UART is the transport. I'm wondering if the GPIO script is necessary. The BCM20710 manual states on p.29 "The CTS and RTS signals of the UART interface are used for BT wake (CTS) and Host wake (RTS) functions in addition to their normal function on the UART interface. Note that this applies for both H4 and H5 protocols." So asserting RTS on the host will wake the controller (its CTS goes low). This would mean the BT_WAKE GPIO would be unnecessary. Also the Broadcom tool sends an HCI reset command first. Could this be the same kind of reset as the GPIO control line? If so then the problem could be simply setting up the UART on the host correctly. The command stty -F /dev/ttyS1 --all on the 3.4 kernel and stty -F /dev/ttyS2 --all on the 3.19 kernel might give a clue as to what has changed in the initial configuration of the serial lines. Also for testing I wonder if cat /dev/ttyS2 | hexdump -C on one host terminal then something like echo -n -e "\x01\x03\x0c\x00" > /dev/ttyS2 on another host terminal would be any help. This example is the HCI reset command, but it may be a simple echo of any text would be enough to demonstrate the host and controller are talking correctly. The device apparently doesn't send when host RTS is negated. The responses are buffered because I can get them later when I assert RTS. This is good. It shows that full duplex handshaking is taking place. The best explanation I could find of this was https://bluegiga.zendesk.com/entries/23143152--REFERENCE-Using-or-bypassing-flow-control-with-UART-communication I think the host UART driver ( serial8250 ) should be dealing with the handshaking. It is hopefully just a question of getting it configured correctly at start up. I tried sending some H5-specific commands but got no response. Ho hum, another theory bites the dust. Thanks for trying it. Al -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
