nRF9160: LTE Sensor Gateway on Thingy:91

[Mattchew]

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?

[Sigurd]

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.

[Mattchew]

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

[Sigurd]

Hi,

ArchDevel said:

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.

ArchDevel said:

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.

ArchDevel said:

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)

[ArchDevel]

Hey Sigurd

Sigurd said:

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?

Sigurd said:

The Thingy:52 advertises with a specific UUID in the advertising packet.

Sigurd said:

This does not apply here.

Perfect! Thank you!

Kindest Regards, 

Arch

[ArchDevel]

Sigurd

Update:

I was able to get the Thingy:52 to connect to the Thingy:91 successfully, and after some time the simulated GPS data was pushed to the cloud and populated in the Asset Tracker Card. Orientation tracking also seems to work quite well. 

[Cody]

Looking forward to the new patch now that it appears v1.1 has been tagged.

[Dheeraj]

Hi Sigurd,

I am new to thingy91. 

And I am doing one of customer project and need to get the BLE values from nRF52840 to nRF9160 (PCA20035).

So, as suggested above, I have flashed "nRF52840_pca20035_hci_uart.hex" on  nRF52840 SoC (PCA20035) and "nRF9160_pca20035_lte_ble_gateway.hex" on nRF9160 SiP (PCA20035), but unfortunately I did NOT see any logs from nRF9160 and nRF52840 on Teraterm.

NOTE: I have flashed via nRF9160 DK (10090) using SWD cable.

I have tried to connect the Thingy91 (PCA20035) to PC using USB cable, but did NOT see any USB ports to get the logs. 

Please let me know If i am missing anything here to establish the connection between nRF52840 and nRF9160 on Thingy91 (PCA20035).

Thanks

[Sigurd]

UPDATE for NCS v1.1.0:

As promised, here are the updated patch files for NCS v1.1.0:

lte_gateway_thingy91_v1.1.0_R2.zip

New in these patch files, compared to the last patch, is added support for logging over UART. So now you can use LTE link monitor with the lte_ble_gateway sample on Thingy:91, both for AT-commands and logging. This was done by merging the hci_uart sample with the usb_uart_bridge sample, into a new sample called hci_uart_with_usb_uart_bridge. Select PCA20035 in the LTE link monitor for this. 

List over new and modified files in the patch:

In the nrf repo, the following files are new or modified:

        new file:   boards/arm/nrf52840_pca20035/CMakeLists.txt
        modified:   boards/arm/nrf52840_pca20035/Kconfig
        modified:   boards/arm/nrf52840_pca20035/Kconfig.defconfig
        new file:   boards/arm/nrf52840_pca20035/board.c
        modified:   boards/arm/nrf52840_pca20035/nrf52840_pca20035.dts
        modified:   boards/arm/nrf52840_pca20035/nrf52840_pca20035_defconfig
        modified:   boards/arm/nrf9160_pca20035/CMakeLists.txt
        modified:   boards/arm/nrf9160_pca20035/Kconfig
        new file:   boards/arm/nrf9160_pca20035/nrf52840_reset.c
        modified:   samples/nrf9160/lte_ble_gateway/CMakeLists.txt
        modified:   samples/nrf9160/lte_ble_gateway/child_secure_partition_manager.conf
        new file:   samples/nrf9160/lte_ble_gateway/nrf9160_pca20035ns.overlay
        modified:   samples/nrf9160/lte_ble_gateway/prj.conf
        new file:   samples/nrf9160/spm/nrf9160_pca20035.overlay
		
In zephyr repo, the following files are new:
		new file:   samples/bluetooth/hci_uart_with_usb_uart_bridge/CMakeLists.txt
        new file:   samples/bluetooth/hci_uart_with_usb_uart_bridge/nrf52840_pca20035.conf
        new file:   samples/bluetooth/hci_uart_with_usb_uart_bridge/nrf52840_pca20035.overlay
        new file:   samples/bluetooth/hci_uart_with_usb_uart_bridge/src/main.c

Make sure that you are on the v1.1.0 tag when applying the patch with git apply. If you are for some reason not able to apply the patch, then I recommend manually changing the files shown in the patch.

Also make sure to update the modem firmware on the nRF9160 to v1.1.0 (download from here)

By the default, the GPS simulator is used in the lte_ble_gateway sample. If you are planning to use the real GPS, it's recommend to update to bsdlib v0.5.1 (make this change, and run west update)

Note that the COM-port is re-enumerated if the nRF9160 resets the nRF52840.

It's also recommend to add your Thingy:91 to nRFCloud before testing the lte_ble_gateway.

The lte_ble_gateway will send data to the cloud when the orientation of Thingy:52 gets flipped(Orientation: 3). If you want to send the data on e.g. button-push also, you can add this code to the bottom of gps_trigger_handler()

	if(has_changed)
	{
		alarm();
	}

EDIT: Replaced "lte_gateway_thingy91_v1.1.0.zip" with a new version. The power_thread() in hci_uart_with_usb_uart_bridge was removed, so that the sample also works when the USB cable is detached from the Thingy91.

BR,

Sigurd

[Dheeraj]

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

[Cody]

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.

[Sigurd]

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.

[Cody]

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.