lte_ble_gateway on Thingy 91 (v1.9.1)

[Simon]

Hello,
trying to get v1.9.1 lte_ble_gateway working on Thingy 91.
Using Thingy 2020:23 1.4.0, which works all good with zip thingy91_fw_2022-02-17_ec486dab (tracker, nrf cloud, mfw_nrf9160_1.3.1).

Using VS to build merged.hex for hci_lpuart (thingy91_nrf52840) and lte_ble_gateway (thingy91_nrf9160_ns),
and flash using 10-pin external debug probe onto nRF52 and nRF91 respectively on Thingy 91.

Not sure if this is the correct way to re-purpose lte_ble_gateway for Thingy 91,
probably not since the following did not produce flashing led or a connection to nrf cloud.

nrfjprog -f nRF52 --eraseall
nrfjprog -f nRF52 --program hci_lpuart-build_2-merged.hex --verify --reset --log

nrfjprog -f nRF91 --eraseall
nrfjprog -f nRF91 --program lte_ble_gateway-build_2-merged.hex --verify --reset --log

(build_1 is for nRF9160-DK which works fine to nrf cloud, build_2 is Thingy 91)(thing-91_build_2-log-1.txt)

Then going back to:
thingy91_nrf52_connectivity_bridge_2022-02-17_ec486dab.hex
thingy91_asset_tracker_v2_ltem_2022-02-17_ec486dab.hex
to use MCUboot,
using VS build_2 of app_signed for nrf52 and nrf91.
Then starting with lte_ble_gateway then hci_lpuart (because usb is lost to Programmer after flashing nrf52).
And this produced no results for led and nrf cloud, just like merged.hex.

I came across this post,
https://devzone.nordicsemi.com/f/nordic-q-a/52689/nrf9160-lte-sensor-gateway-on-thingy-91/225659#225659

which had two hex's to try, but built for an earlier modem, has Thingy 91 resetting without a stable connection.
nrfjprog -f nRF52 --eraseall
nrfjprog -f nRF52 --program hci_uart_with_usb_uart_bridge_nrf52840_pca20035.hex --verify --reset --log

nrfjprog -f nRF91 --eraseall
nrfjprog -f nRF91 --program lte_ble_gateway_nrf9160_pca20035ns.hex --verify --reset --log

In that ticket, the nrf52 hex was done by merging hci_uart sample with usb_uart_bridge (v1.3.0)
For v1.9.1, connectivity_bridge is now used instead of usb_uart_bridge.
This directory no longer exists in v1.9.1 nrf\samples\usb\usb_uart_bridge\src\main.c.

The solution here might be merging connectivity_bridge with hci_lpuart,
or if this will even get me to the appropriate solution for a lte_ble_gateway on Thingy 91?

Maybe I missed a recent solution somewhere on devzone, but not seeing anything like this on my searches.

thank-you,

4861.thing-91_build_2-log-1.txt

[Øyvind]

Hello, 

Per nRF9160: LTE Sensor Gateway documentation in nRF Connect SDK tag 1.9.1 this sample supports nRF9160DK only. 

I came across this post,
https://devzone.nordicsemi.com/f/nordic-q-a/52689/nrf9160-lte-sensor-gateway-on-thingy-91/225659#225659

This is fairly outdated. You can have a look at the GitHub repo here https://github.com/sigurdnev/sdk-nrf/tree/main/samples/nrf9160/lte_ble_gateway

No, plans of updates from what I can tell. 

Kind regards,
Øyvind

[Simon]

from your suggested link,
https://github.com/sigurdnev/sdk-nrf/tree/main/samples/nrf9160/lte_ble_gateway

there is this commit by Carl Richard Steen Fosse <[email protected]>,
https://github.com/sigurdnev/sdk-nrf/commit/77329a6c2a1767561eab1e5554bed282e167076e
which has:
thingy91: Adding support for BT over HCI for Thingy:91
This commit adds support in board files and samples for using the
nRF52840 on the Thingy:91 as a BT controller.

Checking v1.9.1, it looks like that commit is there for Thingy 91 on both lte_ble_gateway and hci_lpuart.

I tried again this time using straight zephyr.hex files:
nrfjprog -f nRF52 --eraseall
nrfjprog -f nRF52 --program hci_lpuart-build_2-zephyr.hex --verify --reset --log

nrfjprog -f nRF91 --eraseall
nrfjprog -f nRF91 --program lte_ble_gateway-build_2-zephyr.hex --verify --reset --log

but no flashing led or a connection to nrf cloud.
How was this tested by Carl to know that a connection was happening (BT or LTE)?

Seems like this should work.

thank-you,

[Øyvind]

Yes you are right, looks like this is implemented in the nRF Connect SDK v1.9.1. 

Simon said:

but no flashing led or a connection to nrf cloud.

Make sure that you are programming the \build\zephyr\merged.hex on the nRF9160. I programmed both applications using the nRF Connect for VS Code extension, which programmed merged.hex from both projects. 

I was able to get them running on my Thingy:91 sending orientation from the Thingy:52 to nRF Cloud.

[Simon]

great!
had tried merged.hex earlier,
but after reinstalling v1.9.1, thingy 91 now works as a gateway to nrf cloud.

any suggestion as to how to view a log output while testing a connection?

I'm not seeing a main.c for hci_lpuart,
and even if merging connectivity_bridge with hci_lpuart is the right way to go.

thank-you,

[Øyvind]

Simon said:

but after reinstalling v1.9.1, thingy 91 now works as a gateway to nrf cloud.

Happy to hear!

Simon said:

any suggestion as to how to view a log output while testing a connection?

The LTE BLE Gateway uses RTT, configured in lte_ble_gateway\boards\thingy91_nrf9160_ns.conf

CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_UART_CONSOLE=n
CONFIG_LOG_BACKEND_RTT=y

You will need to connect an external debugger e.g. nRF9160 DK (P19) to the Thingy:91 SWD interface (P8) using a 10 pin SWD cable.

Simon said:

I'm not seeing a main.c for hci_lpuart,

In nrf\samples\bluetooth\hci_lpuart\CMakeLists.txt you can see that it uses the main. from 

zephyr\samples\bluetooth\hci_uart\src\main.c

# NORDIC SDK APP START
target_sources(app PRIVATE ${ZEPHYR_BASE}/samples/bluetooth/hci_uart/src/main.c)
# NORDIC SDK APP END

And the configurations in the prj.conf found in nrf\samples\bluetooth\hci_lpuart\prj.conf.

More information on the build system can be found under Application Development in the Zephyr documentation.

Kind regards,
Øyvind

[Simon]

Should have tried RTT again after reinstalling v1.9.1, now receiving the log on VS.

Usually there's an Application branch in VS where main.c is, but looks like you have to go to zephyr\samples,
and not even nrf\samples, to get at the source.

Since connectivity_bridge has a main.c in VS, went with that as the base for a merge,
but a challenge right from prj.conf, and main.c was not any better ending in errors.
(probably not ment to be)

Looks like will have to define specific led's at each key step to know what's going on,
if not able to get a standalone going by USB without a DK.

thank-you,

[Øyvind]

Hi, 

I've discussed the issue with Carl Richard, and there seems to be some documentation missing. He is trying to fix this. 

Combining hci_lpuart and connectivity_bridge isn't straight forward, and at this moment is not supported unfortunately. 

[Simon]

that's fine, all good the way it is,
thank-you,