> > On Wednesday, February 25, 2015 at 12:51:13 AM UTC+11, Al Thomas wrote: > > > > 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. >
If CTS isn't low at the end of the reset pulse the device apparently doesn't react. Besides, any boot process that relied on a signal change at some precise point after the reset pulse would be inherently unreliable in a multi-tasking environment. 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. > Yes, playing with BT_WAKE is probably insignificant. But toggling BT_REST is critical unless the device is already in UART mode. > Also the Broadcom tool sends an HCI reset command first. Could this be the > same kind of reset as the GPIO control line? > I don't think so. The firmware download is preceded and suceeded by HCI_reset. So HCI_reset doesn't clear the device RAM. But BT_REST powers off the device and I assume this will clear its RAM. > 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. > This could make things simpler. If you can configure the serial port for a null-modem environment then it might be possible to use the standard program. Cheers, Steven -- 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.
