This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

bluetooth 5 TCP application stream between nrf52840 DK and nrf52840 Dongle on debian stretch

Hi,

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.

Thanks,

Chuck McP

Parents
  • 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

    4.9.0-4-amd64

    But, intend to move to Raspberry PI Debian Stretch once things work.

    Regards,

    Chuck McP

Reply
  • 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

    4.9.0-4-amd64

    But, intend to move to Raspberry PI Debian Stretch once things work.

    Regards,

    Chuck McP

Children
Related