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.
Sorry for the late reply, have you had any progress on this issue?
rtisys said:So, if I intend to stick w/Zephyr, soft devices won't be a part of my project (Is that correct?).
Yes, that is correct.