Yes thanks I also got that from the discussion. In retrospect, I think my difficulty arouse because I did not connect the RTS/CTS lines on my hardware as would be case for testing on the standard nRF52DK board. As well I assume I couldn't type fast enough to issue all the terminal commands necessary. As a result the Host closed the connection. Unfortunately I haven't been able to retest as I am away from work for at least another week. The Linux Host I was testing with is a VM version of Xubuntu 16.10 however eventually it will be an custom embedded board (similar to a Beagle Bone). The BLE hardware + Host must come up correctly every time or it will be a serious problem.
ALan -----Original Message----- From: will sanfilippo [mailto:[email protected]] Sent: Friday, February 10, 2017 1:23 PM To: [email protected] Subject: Re: BLE HCI support on NRF52DK Hello Alan: I may be reading this incorrectly or mistaken, but the host does not need to see the NOOP from the controller. The controller needs to be ready to receive the HCI Reset command from the host. At least, that is my understanding after the email exchange with Andrzej. I would have thought there would be a retry mechanism as well but that is not the case. So all you need to insure is that the controller is up and running before the host sends the HCI Reset. Am I making sense? :-) > On Feb 10, 2017, at 12:39 PM, Alan Graves <[email protected]> wrote: > > Hi Guys, > > The BLE hardware I have to work with does not provide hardware flow control > with RTS/CTS. The CTS line is grounded and the RTS is left not connected. In > any case the BLE module is on its own board that is internally connected to > the Linux host processor. It is probably safe to assume that in this > situation the Nordic chip will be powered up and expecting the Host to be > ready to receive any messages sent via the BLE HCI before the Linux BlueZ > stack is initialized. Obviously I could arbitrarily delay the NOOP message > timing so that the two ends can be in sync, but to not have a timeout > mechanism on the HCI protocol would seem to me to be a guarantee that a > deadlock condition would occur. Another possibility is that perhaps I can > find a way to keep the BLE hardware in a reset state until the Host is > initialized by driving the RESET signal with a GPIO line. > > ALan > > -----Original Message----- > From: will sanfilippo [mailto:[email protected]] > Sent: Monday, February 06, 2017 5:55 PM > To: [email protected] > Subject: Re: BLE HCI support on NRF52DK > > Ah ok; that is quite interesting. I did not realize that was the case and I > was thinking of an external board that was powered off (and not quite > trusting the state of the flow control lines). > > Then really the only thing we need to make sure on our end is that when UART > is brought up and the flow control line is properly de-asserted the nimble > stack sees any commands that were sent by the host (in the case where the > UART comes up first, then the rest of the nimble stack). > > Will > >> On Feb 6, 2017, at 10:27 AM, Andrzej Kaczmarek >> <[email protected]> wrote: >> >> Hi Will, >> >> I could not find any timeout defined for HCI commands so the problem >> here would be when host should timeout and resend HCI Reset. I think >> we should just assume that hw is designed properly and flow control >> lines are either pulled or driven externally all the time so this is not >> overly complicated. >> Actually, if you check Vol 4 Part A Section 1, it says that objective >> of UART TL is to have both ends on the same PCB and communication is >> free form errors, so there is no case that we suddenly have >> controller disconnected - I'd say above assumption is reasonable :-) >> >> BR, >> Andrzej >> >> >> >> On Sat, Feb 4, 2017 at 12:25 AM, will sanfilippo <[email protected]> wrote: >> >>> Hi Andrzej >>> >>> Thanks for pointing me to Vol 2 Part E, Section 4.4. I was recalling >>> a section of the spec that talked about this but could not find it >>> when I sent this email. Thus, I completely agree that the controller >>> sending a NOOP does not in any way indicate that it reset. It is >>> fine if the controller does send a NOOP, but the host cannot use >>> that as an indication that the controller reset. That does make >>> things a bit tricky though as you mention, but hopefully if >>> something is really badly out of sync the host will figure it out and reset >>> the controller. >>> >>> I was also thinking of the following scenario which I should have >>> explained a bit better. If the controller is powered off, it is not >>> driving the flow control line so I am not sure what would happen HW >>> wise in this case. It could be that the flow control line is >>> floating, and therefore the host could see it in various states. >>> Therefore, I would suspect that when a host issues a HCI Reset and >>> does not get a response for some amount of time, it just keeps issuing the >>> HCI Reset until it gets a response. >>> >>> Given that a controller can send a NOOP on power up, I cant see how >>> we can guarantee that the following will NOT happen: >>> >>> * Host sends HCI Reset >>> * Controller sends NOOP >>> * Controller sends Command Complete w/Reset opcode >>> >>> I can also see this happening: >>> >>> * Host sends HCI Reset >>> * Controller sends NOOP >>> * Nothing else happens >>> >>> I certainly agree that once the controller actively takes control of >>> the flow control line it should honor the HCI Reset although I still >>> see the possibility of the two scenarios described above happening. >>> >>> Regarding HW Error: that is something we can do in the controller as >>> we can look at the reason why the device reset and send a HW error event. >>> >>> >>>> On Feb 3, 2017, at 12:12 PM, Andrzej Kaczmarek < >>> [email protected]> wrote: >>>> >>>> Hi Will, >>>> >>>> On Fri, Feb 3, 2017 at 7:08 PM, will sanfilippo <[email protected]> >>> wrote: >>>> >>>>> 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. >>>>> >>>> >>>> The section you quote is only informative (see section 1.1 of the >>>> same >>>> part) and the diagram is only one of possibilities. The actual >>> requirement >>>> is in Vol 2, Part E, Section 4.4 which states that after power up >>>> host is allowed to send up to 1 outstanding command so 1 credit is assumed >>>> here. >>>> Also controller does not need to send noop, but it is also not an >>>> error >>> to >>>> do so. >>>> >>>> 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. >>>>> >>>> >>>> I guess host can assume that CTS/RTS lines work properly, otherwise >>>> there is no way to detect when controller is ready to receive something >>>> (i.e. >>> is >>>> attached). >>>> >>>> >>>>> 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. >>>>> >>>> >>>> My understanding of spec section I mentioned is that controller >>>> should be always ready to receive HCI Reset after power up. If it >>>> is not, then flow control on transport layer should not be enabled. >>>> >>>> >>>>> 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 >>>>> >>>> >>>> Agree. >>>> >>>> 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. >>>>> >>>> >>>> I think this is the case where host actually does not send HCI >>>> Reset >>> since >>>> controller is not ready and RTS/CTS flow control is not enabled. If >>>> controller enabled hardware flow control, it should receive and >>>> process anything according to spec. >>>> >>>> 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. >>>>> >>>> >>>> No, because controller can send noop at any time and it does not >>>> mean a reset - see section I mentioned earlier. But to be honest I >>>> don't really know how this should be handled properly. Probably the >>>> things would go so wrong (due to states on both sides which are out >>>> of sync) that either controller would eventually issue a hardware >>>> error event or host would request controller since it cannot talk >>>> to it anymore. But it's up to implementations which one will detect this >>>> first, I guess. >>>> >>>> 4. Host and Controller were communicating fine and Host powers >>>> off/on >>>>> * Controller sees a HCI Reset and performs appropriate actions. >>>>> >>>> >>>> Agree. >>>> >>>> >>>>> 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). >>>>> >>>> >>>> I'd say it should - this event is for "some type of hardware >>>> failure" as spec says, so it could well be an assert in firmware. >>>> >>>> >>>>> >>>>> 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 >>>>> >>>>> >>>> BR, >>>> Andrzej >>> >>> >
