I might be getting a bit confused here so hopefully I am making some sense. I seem to recall some discussion around this in the past but I cant recall :-) Anyway...
It is my understanding that the first thing a controller should do when it powers up is send a NOOP. Looking at the Core V4.2 Spec, Vol 6 Part D Section 2 you can see a message sequence chart that shows this. It sounds like folks think MyNewt is different than other controllers in this respect. If so, we can change that behavior, but it makes sense to me to do this, as it will inform the host that the controller has powered up. Of course, there is a chicken and egg problem here. If the controller is not powered up and the host sends a HCI Reset, the host is obviously not going to get a response. I am also not sure one can trust the flow control lines if the board is not powered up but one would hope that RTS/CTS are pulled the proper way if the controller is not powered. Certainly, an interesting issue with the MyNewt HCI firmware would be the order in which the UART gets initialized and when the LL is initialized. In the end, I dont think it should really matter, as the host should have to deal with the controller not being ready to receive the HCI Reset. Here are the basic scenarios and what I would expect: 1. Controller powers up first and host is not powered or not ready * Controller issues NOOP but host does not see it. * Host wakes up and sends HCI Reset. * Host gets Command Complete (with proper opcode) and all is well 2. Host powers up first and controller powers up some time later * Host sends HCI Reset but gets no response. * Host sits in a loop, sending HCI Resets periodically. * If Host gets a NOOP, it knows that the controller has powered up. In this case, the host should issue HCI Reset and should get a Command Complete. * If the Host gets a Command Complete with proper opcode, all is well. 3. Host and Controller were communicating fine and Controller powers off/on * Host will see an “unsolicited” NOOP and should realize that the Controller has just reset. Host should perform appropriate actions. 4. Host and Controller were communicating fine and Host powers off/on * Controller sees a HCI Reset and performs appropriate actions. An interesting case is one where the controller resets for a known reason (i.e. firmware asserts). Should the controller send a HW Error event in this case? Some folks I talked to thought it should; others were not sure. The nimble firmware does not do that; currently the only reason a HW error event is issued is when synchronization is lost between the host and controller (See Vol 4 Part A Section Part 4 Error Recovery). Comments/Thoughts? > On Feb 3, 2017, at 4:07 AM, Szymon Janc <[email protected]> wrote: > > Hi Alan, > > On 3 February 2017 at 07:16, Alan Graves <[email protected]> wrote: >> Hi Szymon, >> >> I don't think waiting for the NOP before attaching made any difference, but >> now I can't remember so I'll have to check that. In any case here is the >> btmon output I got during my initial testing: >> >> $ sudo btmon >> [sudo] password for alan: >> Bluetooth monitor ver 5.41 >> = Note: Linux version 4.8.0-34-generic (x86_64) >> 0.977791 >> = Note: Bluetooth subsystem version 2.21 >> 0.977792 >> = New Index: 00:00:00:00:00:00 (Primary,UART,hci0) [hci0] >> 121.060311 >> = Open Index: 00:00:00:00:00:00 [hci0] >> 121.066478 >> < HCI Command: Reset (0x03|0x0003) plen 0 [hci0] >> 121.070996 >> = bluetoothd: Bluetooth daemon 5.41 >> 121.092783 >> = bluetoothd: Starting SDP server >> 121.104354 >> = bluetoothd: Bluetooth management interface 1.13 initialized >> 121.112600 >>> HCI Event: Command Complete (0x0e) plen 3 [hci0] >>> 126.168513 >> NOP (0x00|0x0000) ncmd 1 >> = Close Index: 00:00:00:00:00:00 [hci0] >> 131.246188 >> > > I suspect that HCI Reset is simply ignored before NOP is sent and > Linux will not try sending another command before getting Command > Status for it. > And that will never happen since command was ignored ie. Zephyr has > special config option when used with Mynewt based BT firmware to > handle this > exact situation - send HCI Reset only after initial NOP was received. > Linux on the other hand assumes that once device is attached it is > ready to > receive initial HCI Reset. > >> ALan >> >> -----Original Message----- >> From: Szymon Janc [mailto:[email protected]] >> Sent: Thursday, February 02, 2017 12:18 PM >> To: [email protected] >> Subject: Re: BLE HCI support on NRF52DK >> >> Hi Alan, >> >> On 2 February 2017 at 19:16, Alan Graves <[email protected]> wrote: >>> >>> Thanks for rechecking. I know I'm not setup with RTS/CTS handshaking on the >>> custom board so that is probably going to be a problem. When I get a chance >>> I'll repeat my tests with a complete serial signal set on the nRF52832 DK >>> board. >>> >>> BTW Do you know if Linux assumes hardware flow control by default and if it >>> is possible to override that configuration somewhere? I've been caught >>> before with hardware flow defaults on PPP over serial on Linux... >> >> btattach has -N, --noflowctl option for disabling flow control. Yet, it is >> not recommended for H4 protocol (actually, H4 spec requires flow control to >> be enabled). >> >> But I'd first check if simply waiting for few seconds before calling >> btattach fix the problem (ie so that Linux sends initial HCI Reset after NOP >> event was emitted). >> >>> ALan >>> >>> -----Original Message----- >>> From: Christopher Collins [mailto:[email protected]] >>> Sent: Wednesday, February 01, 2017 4:00 PM >>> To: [email protected] >>> Subject: Re: BLE HCI support on NRF52DK >>> >>> Hi Alan, >>> >>> On Wed, Feb 01, 2017 at 11:05:23PM +0000, Alan Graves wrote: >>>> Hi, >>>> >>>> I've spent some time trying to get nRF52832 DK running the 'blehci' code >>>> communicating with Xubuntu 16.10 (under VMware) with not much luck. >>> >>> I just ran the latest blehci from develop with the following setup: >>> >>> * BlueZ 5.39 >>> * Ubuntu 16.04 (Xenial) >>> * nRF52832 DK >>> >>> I didn't notice any issues when I tried. I'm afraid I don't see anything >>> wrong with the steps you follows. Maybe one of the following hints will >>> help: >>> >>> * Make sure the two flow control pins (RTS / CTS) are attached. >>> >>> * Try killing btattach and restarting it. When you do this, you should >>> see BlueZ send the host init sequence in btmon (starting with a Reset >>> command). >>> >>> The btattach step is required because the BlueZ host doesn't seem to >>> interpret the no-op event as a controller reset. You have to explicitly >>> tell the host to reset the controller. >>> >>> Hopefully this gets you a little closer to a solution. If you're still >>> seeing the same issue, just let me know and we can debug it further. >>> >>> Thanks, >>> Chris >> >> >> >> >> -- >> pozdrawiam >> Szymon K. Janc > > > > -- > pozdrawiam > Szymon K. Janc
