I also went to the extreme and disabled the flow control in the BlueZ stack by commenting some lines out and rebuilding things. I believe that might not have been strictly necessary as someone mentioned afterwards that flow control could be turned off by a configuration option. ALan
-----Original Message----- From: Łukasz Rymanowski [mailto:[email protected]] Sent: Tuesday, March 28, 2017 6:38 AM To: [email protected] Subject: Re: BLE HCI support on NRF52DK Hi, On 28 March 2017 at 12:10, Łukasz Rymanowski <[email protected]> wrote: > Hi all, > > Just had a need to run my nrf52 dev board with blehci and faced same > issues as Alan > > I think we need update documentation here: > http://mynewt.apache.org/os/ tutorials/blehci_project/ so there is no > need to grep mailinglist for that :) > > We have two issues in the line which says how to attach controller; > > sudo btattach -B /dev/ttyUSB0 -S 11520 > > 1. Speed is incorrect. Default one which is set in > net/nimble/transport/uart/syscfg.yml > > BLE_HCI_UART_BAUD: > description: 'The baud rate of the HCI uart interface' > value: 1000000 > > BTW We could mention that this can be configured by setting > BLE_HCI_UART_BAUD for example in apps/blehci/syscfg.yml > > 2. We should also mention that if there is no CTS/RTS lines present in > the test environment, flow control should be turned off. It can be > done with -N option for btattach. Note: -N option came with BlueZ ver > 5.44 > and of course BLE_HCI_UART_FLOW_CTRL shall be set to 0 then. > > > > On 27 February 2017 at 19:52, Alan Graves <[email protected]> > wrote: > >> Thanks, I did see that over the weekend. Someone must be looking over >> my shoulder :) >> >> -----Original Message----- >> From: Szymon Janc [mailto:[email protected]] >> Sent: Sunday, February 26, 2017 11:19 AM >> To: [email protected] >> Subject: Re: BLE HCI support on NRF52DK >> >> Hi, >> >> On 25 February 2017 at 01:54, Christopher Collins <[email protected]> >> wrote: >> > Hi Alan, >> > >> > On Sat, Feb 25, 2017 at 12:21:15AM +0000, Alan Graves wrote: >> >> Well my conclusion is that the HCI mode is frustrating at best to >> >> use >> on the BlueZ stack! >> >> >> >> In my initial attempts to talk to the controller I use this command: >> >> $ sudo btmgmt --index 1 >> >> [sudo] password for alan: >> >> [hci1]# >> >> >> >> First thing I noticed is that the MyNewt HCI mode tutorial says to >> >> set >> the static address: >> >> [hci1]# static-addr cc:00:00:00:00:00 Set static address failed >> >> with status 0x0b (Rejected) >> > >> > I believe you can only configure an address while the controller is >> > "powered off" (scare quotes because the board doesn't actually have >> > to be powered off, BlueZ just has to consider it to be in the >> > powered off state). Try the following from btmgmt: >> > >> > power off >> > static-addr cc:00:00:00:00:00 >> > power on >> > >> >> This doesn't work on my system. I'm not sure what the problem is, >> >> but perhaps the initial BT addr 00:00:00:00:00:00 is a clue? >> > >> > The all-zero address indicates that your controller is not >> > configured with a public address. With no public address and no >> > random address you are pretty restricted in what you can do. >> > >> > Hopefully this resolves some of the issues you're seeing. I'm >> > afraid my knowledge of BlueZ is pretty poor, so I can't say if >> > there is any issue with the C program >> >> >> Just released BlueZ 5.44 has added support for this :) >> >> From release notes: >> "support for using single-mode (LE-only) controllers that lack a >> public address (therefore necessitating the use of a static random >> identity address). E.g. any nRF5x controller running a MyNewt or >> Zephyr based firmware falls into this category." >> >> So there should be no need for setting this up manually with btmgmt >> anymore. >> >> -- >> pozdrawiam >> Szymon K. Janc >> > >
