From: Steven Saunderson <essat2...@gmail.com> Sent: Monday, 23 February 2015, 8:43 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
I've checked stty. The -clocal option causes patchram to hang when opening the serial port. The crtscts option doesn't help unfortunately. If this handshaking is done properly I'd expect the host to leave RTS off until there is something to send. Then it should raise (i.e assert) RTS, wait for CTS, send the data, then drop RTS. So this wouldn't leave RTS asserted which is what we want. Thanks for trying. Thinking about it, the cread switch of stty probably doesn't affect RTS on the host, but CTS. Your description of handshaking made me wonder if that was the problem. Are you aware there are two serial protocols available on the chip? H4 uses the control lines and H5 that seems to use SLIP. Page 30 of the BCM20710 manual says "H5 requires the use of an external LPO. CTS must be pulled low." So if RTS is asserted on the host to switch to UART transport after reset and RTS is kept high (so CTS low on the controller) the controller may expect H5. There is a Broadcom H5 version of the tools so I may try that when I get set up. I have come across something suggesting RTS is set on the host when a serial port device file is opened as part of the POSIX spec ( http://stackoverflow.com/questions/5090451/how-to-open-serial-port-in-linux-without-changing-any-pin ) although not found any verification yet. This may be why you found you had to open the file before running the Broadcom tool so RTS was asserted on the host to get the UART selected after reset. I will look for a way to assert and de-assert RTS from the command line. My theory is this switches to UART transport after reset and then because CTS will then go high on the controller the controller will expect H4 protocol. The other thing I noticed is the Broadcom reset command is the HCI reset command and not a vendor specific command. I'm hoping this will give me a nice test case that the host and controller are talking the right serial protocol. So send 0x01, 0x03, 0x0c, 0x00 and get back 0x04, 0x0e, 0x04, 0x01, 0x03, 0x0C, 0x00 See: http://processors.wiki.ti.com/index.php/CC256x_VS_HCI_Commands#Command_Packethttps://code.google.com/p/smalltooth/wiki/HostControllerInterface#Bluetooth_Controller_setup:https://code.google.com/p/broadcom-bluetooth/source/browse/brcm_patchram_plus.c#171 Anyway there is a lot for me to try when I get that far. All the best, 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
