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

nRF9160: LTE Sensor Gateway on Thingy:91

I am trying to fun the LTE Sensor Gateway on the Thingy:91.

The boards are missing from zephyr so I copied nrf52840_pca20035 and nrf9160_pca20035 from ncs\nrf\boards\arm.

When running samples/bluetooth/hci_uart.

The BLE and UART don't seem to be configured correctly. I get "warning: BT_CTLR_DTM_HCI" and "warning: BT_CTLR_ASSERT_HANDLER".

I created ncs\zephyr\samples\bluetooth\hci_uart\nrf52840_pca20035.overlay based on https://devzone.nordicsemi.com/f/nordic-q-a/51693/hci_uart-on-thingy-91

This still doesn't work.

Adding the lines below to nfr52840_pca20035\Kconfig.defconfig seem to fix the BLE issues? UART is not working so, I don't know if it is working.

config BT_CTLR
default BT

When running samples/nrf9160/lte_ble_gateway I get errors "warning: UART_2_NRF_UARTE" and "warning: UART_2_NRF_FLOW_CONTROL"

I see that nrf9160_pca20035ns.overlay is missing from the folder but I am not sure how to modify it. There is no status light configured. 

Help?

Parents
  • Hi,

    The Thingy:91 is not configured for this use-case at this time. A colleague of mine tested this a couple of days ago, and here it the changes/files used:

    thingy_91_lte_changes.zip

    nrf_changes.diff applies to ncs/nrf

    zephyr_changes.diff applies to ncs/zephyr

    nrf52840_pca20035.conf and .overlay should be placed in ncs/zephyr/samples/bluetooth/hci_uart/

    nrf9160_pca20035.overlay should be placed in ncs/nrf/samples/lte_ble_gateway/

    Use Segger RTT viewer to view the log output. Note that you need to manually keep the nRF52 in reset for several seconds before releasing it. Holding it in reset is done by grounding TP8 (apply patch to enable reset pin). On the nRF91-DK we are using a GPIO line between the nRF52 and nRF91 in order to reset the nRF52. I believe it should be possible to add this functionality to the thingy:91 as well, by using one of the lines originally used by the UART, e.g. pin 20. But there are some bugs on the master branch at the moment, so this reset functionality is currently not working reliably.

  • I don't see the device show up on nRF Cloud. I also am not able to see anything on the RTT viewer. 

  • Not sure what changed, no I can see it in RTT.

    nRF91 is showing:

    00> ***** Booting Zephyr OS build v1.14.99-ncs3-snapshot2-2647-gd6e67554cfeb *****
    00> 
    00> Application started
    00> 
    00> Initializing Bluetooth..
    00> 
    00> Establishing LTE link (this may take some time) ...
    00> 
    00> ASSERTION FAIL [err == 0] @ C:/Nordic_SDK/ncs/zephyr/subsys/bluetooth/host/hci_core.c:340
    00> 
    00> k_sem_take failed with err -11
    00> 
    00> [00:00:11.804,351] <err> os: r0/a1:  0x00000004  r1/a2:  0x00000154  r2/a3:  0x00000000
    00> [00:00:11.804,351] <err> os: r3/a4:  0x00000002 r12/ip:  0x00000000 r14/lr:  0x00014ee3
    00> [00:00:11.804,351] <err> os:  xpsr:  0x41000000
    00> [00:00:11.804,382] <err> os: s[0]:  0x00000000  s[1]:  0x00000000  s[2]:  0x00000000  s[3]:  0x00000000
    00> 
    00> [00:00:11.804,382] <err> os: s[4]:  0x00000000  s[5]:  0x00000000  s[6]:  0x00000000  s[7]:  0x00000000
    00> 
    00> [00:00:11.804,412] <err> os: s[8]:  0x00000000  s[9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
    00> 
    00> [00:00:11.804,412] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  00
    00> 

    nRF52 is showing:

    [00:00:00.000,549] <inf> bt_hci_raw: Bluetooth enabled in RAW mode
    [00:00:00.004,455] <inf> usb_cdc_acm: USB device suspended
    [00:00:00.004,455] <inf> usb_cdc_acm: USB device suspended
    [00:00:00.102,935] <inf> usb_cdc_acm: USB device resumed
    [00:00:00.102,966] <inf> usb_cdc_acm: USB device resumed
    [00:00:00.219,573] <inf> usb_cdc_acm: USB device configured
    [00:00:00.219,573] <inf> usb_cdc_acm: USB device configured

  • I can see it in RTT.

    Good. Did you ground TP8 at startup?

    Note that you need to manually keep the nRF52 in reset for several seconds before releasing it. Holding it in reset is done by grounding TP8

    I will see if I can get a reset-line between nRF52 and nRF91 working automatically.

  • Hello,

    This example still does not work on the Thingy:91.

    The Thingy:91 never seems to connect to the Thingy:52. 

     ASSERTION FAIL [err == 0] @ C:/Nordic_SDK/ncs/zephyr/subsys/bluetooth/host/hci_core.c:340

    The don't think the LTE ever connects so I don't ever see it come up on nRF Cloud. 

  • Hello ,

    Still need help getting the LTE Sensor Gateway working on the Thingy:91.

    Thanks,

    Matt

  • Hi,

    I got the automatic reset-line to work. I got the Thingy:91 to connect to a Thingy:52 over BLE, and when I flipped the Thingy:52, the orientation got posted to nRFCloud. Might be better ways to do it, but at least it works. Note that I have not tested it very thoroughly, so might potentially be some minor bugs present.

    I tested this on nrf(fw-nrfconnect-zephyr) master, hash d4a23f96221fce9bff846a2979d304c0130d6b74

    Here are git diffs, and pre-compiled hex:

    lte_ble_gateway_thingy91.zip

    EDIT: 

    Minor bug-fix: for samples/nrf9160/spm/nrf9160_pca20035.overlay, and  samples/nrf9160/lte_ble_gateway/nrf9160_pca20035ns.overlay , the rts-pin should be set to 0xFFFFFFFF , not 0xFF

Reply
  • Hi,

    I got the automatic reset-line to work. I got the Thingy:91 to connect to a Thingy:52 over BLE, and when I flipped the Thingy:52, the orientation got posted to nRFCloud. Might be better ways to do it, but at least it works. Note that I have not tested it very thoroughly, so might potentially be some minor bugs present.

    I tested this on nrf(fw-nrfconnect-zephyr) master, hash d4a23f96221fce9bff846a2979d304c0130d6b74

    Here are git diffs, and pre-compiled hex:

    lte_ble_gateway_thingy91.zip

    EDIT: 

    Minor bug-fix: for samples/nrf9160/spm/nrf9160_pca20035.overlay, and  samples/nrf9160/lte_ble_gateway/nrf9160_pca20035ns.overlay , the rts-pin should be set to 0xFFFFFFFF , not 0xFF

Children
  • Thank you! This is working a lot better!

    Should the rts-pin take place of the TP8 short? It doesn't seem to..

    There is a warning on the compile. I think it is causing an issue. The Thingy:91 seems to randomly crash. 

    nrf52840_reset.c

    while (uart_fifo_read(h4, &c, 1)) {
    		continue;
    	}

    implicit declaration of function 'uart_fifo_read'; did you mean 'uart_drv_cmd'? [-Wimplicit-function-declaration]

  • Should the rts-pin take place of the TP8 short? It doesn't seem to..

    No. RTS is disconnected. You don't need to do anything with TP8 with the new changes.

    As mentioned, the code was not thoroughly tested. I just saw that it was able to get data over BLE from Thingy52 to Thingy91, and then the Thingy91 sent it to the cloud.

    The Thingy:91 seems to randomly crash

    When this happens, did you see any error-logs being printed over RTT from the nRF9160? If not already done, you might also want to enable RTT on the nRF52840(hci-uart), and see if any errors are being printed there also. 

  • Hello ,

    I was directed to this thread by Håkon as I am currently attempting to do the same thing; use the Thingy:91 with the lte_ble_gateway and a Thingy:52, for a proof of concept in the smart energy sector.

    I have downloaded your .diff files and tried to utilize the:

    git apply nrf_patch.diff
     

    and 

    git apply zephyr_patch.diff

    commands in the respective root directories and was greeted with error codes that echo "already exist in working directory" and "patch does not apply." Is it safe to assume that these changes to support the Thingy:91 made it into the v1.1-branch nrf tree?

    I proceeded forthwith writing the precompiled hex files to the respective controllers on the Thingy:91, I was able to successfully connect to the cloud after the firmware update. However, I am confused as to how to get the Thingy:52 to connect as the readme is written for the nrf9160dk and talks about a pattern that must be entered. 


    1. The first time you start the sample, pair the device to your account:

      1. Observe that both LED 3 and 4 start blinking, indicating that the pairing procedure has been initiated.
      2. Follow the instructions on `nRF Cloud`_ and enter the displayed pattern. In the terminal window, you can see the pattern that you have entered.
      3. If the pattern is entered correctly, the board and your nRF Cloud account are paired and the device reboots. If the LEDs start blinking in pairs, check in the terminal window which error occurred. The device must be power-cycled to restart the pairing procedure.
      4. After reboot, the board connects to the nRF Cloud, and the pattern disappears from the web page.

    I have been successful at getting J-Link RTT Server to identify both the nrf9160 chipset as well as the nrf52 chipset and got RTT Client to "Connect" but am not receiving any output from either chipset. I am certain that I have missed a step. May you shed some light for me and help me work toward a solution?

  • Hi,

    Is it safe to assume that these changes to support the Thingy:91 made it into the v1.1-branch nrf tree?

    No, they are not in the v1.1-branch. I was on master commit d4a23f96221fce9bff846a2979d304c0130d6b74 when the patch was made, you likely need to be on the same commit to use the patch directly. If not, you need to manaully add the changes.

    Once v.1.1 is tagged, I will create a new patch and do some refactoring of the code in the patch.

    I am confused as to how to get the Thingy:52

    The Thingy:52 advertises with a specific UUID in the advertising packet. The Thingy:91 is scanning for BLE advertising packets, and will auto-connect if this UUID is found when scanning.

    and talks about a pattern that must be entered. 

    This does not apply here. This pattern is for adding non-JITP nRF91-DKs to the nRF Cloud. (DKs without pin-code)

  • Hey 

    I was on master commit d4a23f96221fce9bff846a2979d304c0130d6b74 when the patch was made

    Thank you for shedding some light on the operation and behind the scenes of this patch. Firstly, I created a new branch with this commit:

    git checkout -b master_thingy91 d4a23f96221fce9bff846a2979d304c0130d6b74

    Then updated with west, but the same sequence of errors are still present when I "git apply" in the root of the respective directories. Am I doing this correctly?

    The Thingy:52 advertises with a specific UUID in the advertising packet.
    This does not apply here.

    Perfect! Thank you!

    Kindest Regards, 

    Arch

Related