I'm developing an application with the following hardware and software design components:
- nrf52840 DK with attached sensor
- nrf52840 USB dongle attached to debian stretch (i86 now, soon to be raspberry pi) platform
- Zephyr development environment for nrf52840 platforms (working well!)
-Need to implement application-level TCP stream between linux app and sensor readout code on nrf52840 DK
- hopefully run Bluetooth 5 (as opposed to ble 4.2)
Rather than jump into the particular problems I'm having, it might be worth asking what approach is best.
I assume that using IPSP over IPV6 is the right path to take. I have built and run a Zephyr IPSP sample
test on the DK and can see it listening for a connection. On the linux end, I have installed the dongle and
played a bit with nrfConnect. The device shows up and can be downloaded - and can connect to the
DK nrf52 using the one of the nrfConnect programs. So I can download (some) firmware and find the
far end nrf52.
However, when I try to finish the linux setup for IPSP, bluetoothctl does not find a bluetooth capable device.
I discovered that I need to load HCI-capable firmware into the dongle...fine. One of the earlier notes on the
process described building and loading the Zepher HCI-USB sample code for this purpose. Since the dongle
board is supported in Zephyr (nrf52840_pca10059), I built the hex image and tried to load it using nrfConnect.
NrfConnect can access both the file and dongle; but will not load the firmware because it apparently starts at
address 0 (?). Since image addresses are usually dictated by the board support config files, I assumed that
was taken care of in the board support files. Am I missing something here?
Also, is there a path to accomplish what I'm after by using the softdevice (140 ?) driver. I've read that the HCI
interface is not exposed, but as long as I can get a TCP socket, I don't really need to see that.
Looking for the cleanest implementation path with the fewest moving parts possible.
I've done a bit more digging and have cleared up some of my misconceptions about what layers do what functions......this may all be "old news" to most BT developers, but the following - and, particularly, comments and corrections - may be of help to other new comers. Thanks in advance.
-Some of my pca10059 download issues might be due to lack of JTAG support chip on that board. Several posts discuss using a pca10056 (DK) to address that problem. WIll get a flash cable and try to "play through" the pca10056 to program the pca10059 once I get a handle on the software issues (see below).
- I found a white paper that describes the role of softdevices (Nordic) vs Zephyr stack (Nordic contributed). So, if I intend to stick w/Zephyr, soft devices won't be a part of my project (Is that correct?). Also, since I need to get a reliable byte stream into my Linux platform, I will need an exposed HCI interface for the hci daemon and higher stack levels. That's another reason to focus on the hci firmware.
- The Zephyr hci-usb seems to be a placeholder at present waiting for further development. Don't know if anyone is currently working in that area.
-Looks like I should be using Zephyr hci-uart. Without doing some rewire on the pca10059, I'm guessing the best thing to do is use a pca10056 DK to run the hci-uart firmware. Luckily, I have several of these, so no problem. It builds and runs on the DK. (cmake -DBOARD=nrf52840_pca10056 ,,/,,/ in Zephyr tool chain). There was at least one note that hci-uart would only support BT 4.2 and not BT 5...don't know just what this means-or if its accurate.
-hciattach (or btattach) appears to find the pca10056 runing hci-uart firmware on linux device /dev/ttyACM0. But, hciconfig shows it as DOWN. Attempts to bring it up with "hciconfig hc0 up" yield an error 99 - see below.
sudo hciconfig dev
hci0: Type: Primary Bus: UART BD Address: 00:00:00:00:00:00 ACL MTU: 27:7 SCO MTU: 0:0 DOWN RX bytes:231 acl:0 sco:0 events:16 errors:0 TX bytes:88 acl:0 sco:0 commands:16 errors:0
sudo hciconfig hci0 up
Can't init device hci0: Cannot assign requested address (99)
OS is Debian Stretch
But, intend to move to Raspberry PI Debian Stretch once things work.