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. 

  • Hi Sigurd,

    My heartily thanks for you, for the changes above. 

    Today I have ported all the above code and tested. But unfortunately, I didn't get the desired output.

    Steps followed.

    1. I was on V1.1.0 branch

      git branch
    * (HEAD detached at v1.1.0)
    master

    2. I have manually ported all the code changes and built. No issues found while building the code.

    3. Flashed the hci_uart_with_usb.hex on nrf52840_pca20035 (via nrf9160 DK using SWD cable)

       (But no logs seen in RTT viewer, even though I have added a few prints)

    4.Observed the 1 COM port extra, dedicated to Thingy91. (Typically 2 COM ports should appear, but seen only 1 COM port)

    5. Flashed the ble code changes on nrf9160_pca20035ns (via nrf9160DK using SWD cable).

    Observed the below crash logs

    /************************     Crash Logs   ****************************/

    SPM: NS image at 0xc000

    SPM: NS MSP at 0x2002c1e0
    SPM: NS reset vector at 0x1503d
    SPM: prepare to jump to Non-Secure image.


    ***** Booting Zephyr OS build v2.0.99-ncs1 *****

    <err> at_host: UART check failed: 12. Dropping buffer and retrying.    // 1st Error
    Application started
    Initializing Bluetooth..
    Establishing LTE link (this may take some time) ...
    [00:00:02.163,452] <dbg> lte_lc.w_lte_lc_connect: Network mode: AT%XSYSTEMMODE=1,0,1,0
    ASSERTION FAIL [err == 0] @ /home/spanidea/v1.1.0/zephyr/subsys/bluetooth/host/hci_core.c:340
    k_sem_take failed with err -11
    [00:00:12.270,812] <err> os: r0/a1: 0x00000004 r1/a2: 0x00000154 r2/a3: 0x00040d1c
    [00:00:12.437,774] <err> os: r3/a4: 0x00000154 r12/ip: 0x00000000 r14/lr: 0x00016cf7
    [00:00:12.604,736] <err> os: xpsr: 0x61000000
    [00:00:12.708,923] <err> os: s[0]: 0x00000000 s[1]: 0x00000000 s[2]: 0x00000000 s[3]: 0x00000000

    [00:00:12.897,216] <err> os: s[4]: 0x00000000 s[5]: 0x00000000 s[6]: 0x00000000 s[7]: 0x00000000

    [00:00:13.085,479] <err> os: s[8]: 0x00000000 s[9]: 0x00000000 s[10]: 0x00000000 s[11]: 0x00000000

    [00:00:13.273,986] <err> os: s[12]: 0x00000000 s[13]: 0x00000000 s[14]: 0x00000000 s[15]: 0x00000000

    [00:00:13.344,055] <err> os: fpscr: 0x000182f1

    [00:00:13.369,262] <err> os: Faulting instruction address (r15/pc): 0x000396ae
    [00:00:13.397,094] <err> os: >>> ZEPHYR FATAL ERROR 4: Kernel panic
    [00:00:13.443,725] <err> os: Current thread: 0x200293a8 (unknown)
    [00:00:13.490,203] <err> os: Halting system

    /**********************************************************************/

    NOTE: 

    As per my requirement, I need this ble values in asset_tracker application. Hence I have lte_ble_gateway code changes with asset_tracker application. Same code changes are working nrf9160 DK (10090) without any issues. 

    I have attached below files. I strongly believe, maybe I am missing some configurations in order to get this issue fixed. 

    I am requesting you to help me in review the attached files and let me know the missing changes. 

    1. asset_tracker --> build --> zephyr --> merged.hex

    2. asset_tracker --> Kconfig, nrf9160_pca20035ns.overlay, prj_nrf9160_pca20035.conf

    3. hci_uart_with_usb_uart_bridge --> build --> zephyr --> zephyr.hex

    4. hci_uart_with_usb_uart_bridge --> src --> main.c

    5. hci_uart_with_usb_uart_bridge --> CMakeLists.txt, nrf52840_pca20035.overlay, nrf52840_pca20035.conf

    Board configurations:

    nrf9160_pca20035, nrf52840_pca20035

    Thank you for your time and great help. 

    NOTE: Its completely blocking my production. 

        

     asset_tracker_ble_v1.1.0.zip

  • Hey Sigurd,

    First of all, thanks for all your help.

    I can confirm the results that Dheeraj posted above, even with the default hex files that you provided the Thingy91 crashes with the same crash logs that Dheeraj provided.

    This is blocking our team as well.

  • Hi,

    The following steps works for me:

    Turn Thingy91 on, and plug in the 10-pin programming cable.

    Set the SWD select switch to nRF52, and program the nRF52:

    nrfjrpog -e
    nrfjprog -f nRF52 --program hci_uart_with_usb_uart_bridge_nrf52840_pca20035.hex --verify --reset

    Set the SWD switch to nRF91, and program the nRF9160:

    nrfjrpog -e
    nrfjprog -f nRF91 --program lte_ble_gateway_nrf9160_pca20035ns.hex --verify --reset

    Turn Thingy91 off. Remove 10-pin programming cable.

    Plug the USB cable into the Thingy91.

    Turn Thingy91 on.

    Open LTE link monitor, and select PCA20035.

    Again, note that the COM-port is re-enumerated if the nRF9160 resets the nRF52840. So you might need to select PCA20035 in LTE link monitor a second time when this happens.

    This patch was for UART logging. I have not tested Segger RTT logging with this patch.

  • Okay I am trying it again this morning and I have had a little bit of luck, following your directions exactly I can get the Thingy91 to boot up and blink blue LEDS then blue and red LEDS.

    This is with one caveat - I have to have the Thingy91 plugged in to my computer via USB. It appears that if I unplug the USB cable from the Thingy91 and attempt to reboot the device, it will fail.

  • This is with one caveat - I have to have the Thingy91 plugged in to my computer via USB. It appears that if I unplug the USB cable from the Thingy91 and attempt to reboot the device, it will fail.

    You are correct. In the original usb_uart_bridge sample, the nRF52840 is just put into system OFF sleep mode when there is no USB connected. But in our use-case with the LTE gateway, we need the nRF52840 powered on for the BLE HCI.

    Should be a simple fix for this, in hci_uart_with_usb_uart_bridge, modify the function power_thread() in main.c to look someting like this:

    void power_thread(void)
    {
    	while (1) {
    		if (!nrf_power_usbregstatus_vbusdet_get()) {
    			//nrf_power_system_off
    			k_sleep(100);
    		}
    		k_sleep(100);
    	}
    }

    I have not tested this, but alternatively we could perhaps just remove the power thread functionality completely, if the nRF52840 is on all the time anyways.

    I hope this helps. Let me know how it goes.

Reply
  • This is with one caveat - I have to have the Thingy91 plugged in to my computer via USB. It appears that if I unplug the USB cable from the Thingy91 and attempt to reboot the device, it will fail.

    You are correct. In the original usb_uart_bridge sample, the nRF52840 is just put into system OFF sleep mode when there is no USB connected. But in our use-case with the LTE gateway, we need the nRF52840 powered on for the BLE HCI.

    Should be a simple fix for this, in hci_uart_with_usb_uart_bridge, modify the function power_thread() in main.c to look someting like this:

    void power_thread(void)
    {
    	while (1) {
    		if (!nrf_power_usbregstatus_vbusdet_get()) {
    			//nrf_power_system_off
    			k_sleep(100);
    		}
    		k_sleep(100);
    	}
    }

    I have not tested this, but alternatively we could perhaps just remove the power thread functionality completely, if the nRF52840 is on all the time anyways.

    I hope this helps. Let me know how it goes.

Children
  • Thank you Sigurd, will attempt this as soon as I can.

    UPDATE: After applying the power thread related patch above, things appear to be working well. Testing continues, will let you know if I encounter additional issues.

  • Hi Sigurd,

    We have tried the above fix and able to receive the BLE values from nRF52840_PCA20035.

    But we encountered an issue.

    1. Connected the Thingy91(PCA20035)  using USB and SWD cable via nRF9160 DK(PCA10090)

    flashed the hci_uart_with_usb_uart_bridge (NOTE: Disabled the power_thread) on nRF52840_PCA20035 and flashed the application Image on nRF9160_PCA20035. 

    Observed the BLE values and sending to the nRF cloud. --> NO ISSUE

    Issue Scenario:

    2. Now, we have removed thingy91 from USB and SWD cable (Kept thingy91 as standalone), still, BLE values observed and sent to the nRF cloud.

    BUT,

    3. We have tried resetting (Power cycle) the device using nrf9160 SW3 Button, in this particular case we have observed: "Scanning failed to start, err -12".  and NO BLE values observed from nRF52840.

    Recovery: Connect the thingy91 back to the system with USB  and give the power cycle. Observe the BLE values. 

    Expectation: The nRF52840 should send BLE values, though we removed the USB and power cycle the Thingy91 using SW3/SW4.  

    If Thingy91 is NOT connected to USB, nRF52840 should get 1.8V power supply from PMIC (ADP536x), but it looks like this is not happening. Results we need to connected Thingy1 to USB in order to get the BLE values. 

    Please help us in directing to the right way to fix the above issue. 

    NOTE: We have tried to test on 2 Thingy91 devices, observed the same behavior. 

  • Sigurd,

    Hey, sounds like you put in some good work on this. I'm trying to get the same code working but I think I am missing something. I have downloaded the hex files but I don't see the source code to make the changes that have been discussed. I'm sure its in the thread somewhere I just cant find it. Could you please post a link to the source code with segger project file for the hci_uart_with_usb_bridge and the lte_ble_gateway_nrf9160.

  • Hey ,

    It has been quite some time since the last patch for getting the LTE BLE Gateway sample up and running on the Thingy91. It also appears that this thread and your patches have proven quite popular. The last patch was designed for nRF Connect SDK v1.1.0. I am curious if you could update the patch to work on nRF Connect SDK v1.3.0 or if Nordic has another solution that they are recommending? I still don't see official support for the Thingy91 in the LTE BLE Gateway example code on master. Thank you.

Related