Unable to compile for nrf9160_pca20035 (Thingy:91)

[ArchDevel]

I have been at this for a few days now, I have had a number of compilation errors that I have had to work through and find solutions for, but I am stumped on this current error.

First a bit about my system and the development environment:

Arch Linux 5.3.10-arch-1 (System up to date)

Latest Master Zephyr SDK also install in a separate directory.
Latest Master NCS but with the Joakimtoe NRF Fork (This fork solved a whole host of problems for me, but last update was 11 months ago?)

West v0.6.3
Ninja v1.9.0
Cmake v3.15.5
GCC Arm v7 2018-Q2

ZEPHYR_TOOLCHAIN_VARIANT=gnuarmemb
ZEPHYR_SDK_INSTALL_DIR=$HOME/zephyrsdk
GNUARMEMB_TOOLCHAIN_PATH='~/.gnuarmemb'
source zephyr-env.sh using the NCS Zephyr Directory

The sample that I am trying to compile is the lte_ble_gateway sample found in the nrf9160 folder of NCS. After changing into the nrf directory I run the command:

west build -p -b nrf9160_pca20035 samples/nrf9160/lte_ble_gateway

The build successfully compiles 136 of 167 of the objects before stopping with a message of:

ninja: build stopped: subcommand failed.
ERROR: command exited with status 1: /usr/bin/cmake --build /home/rex/.nRFConnectSDK/nrf/build

Where should I begin? There looks to be a number of "Warnings" that are being thrown surrounding nrf_cloud_transport.c

[ArchDevel]

Update!

I swapped the nrf_cloud_transport.c file for the file from the Latest Master NCS NRF tree.

I had to swap out a few parameters for the TX and RX pins, Changed the _##idx##_ out for the corresponding pin numbers as guided by the build output. And it seems as though this has solved that issue. However, now the build is having trouble finding the BSD_limits.h file as it is called via a #include statement by at_cmd.c

I located the file on my system at /nrfxlib/bsdlib/include/bsd_limits.h

Do we know where this particular file is looking for bsd_limits.h?

[ArchDevel]

*Got the NS version to compile just fine. Loaded the HCI_UART sample to the nrf52849. and the lte_ble sample to the nrf9160. Does the thingy have a serial communication protocol over usb? Or is this connection only for Link Monitor? 

I cannot seem to find any supporting documentation around the Thingy:91 and an emulator such as Putty. I hope to dervive the hostname, and peer into the workings of the files so I can understand what is going on. The readme is written for the nrf9160 DK, so I am shooting in the dark without an emulator at the moment. 

[Håkon Alseth]

ArchDevel said:

*Got the NS version to compile just fine. Loaded the HCI_UART sample to the nrf52849. and the lte_ble sample to the nrf9160. Does the thingy have a serial communication protocol over usb? Or is this connection only for Link Monitor? 

I cannot seem to find any supporting documentation around the Thingy:91 and an emulator such as Putty. I hope to dervive the hostname, and peer into the workings of the files so I can understand what is going on. The readme is written for the nrf9160 DK, so I am shooting in the dark without an emulator at the moment. 

 By flashing hci_uart to the nRF52840 on the thingy:91 board, you're then dropping the USB-UART bridge that were previously loaded onto the nRF52840.

This is the original project that is running on the nRF52840: https://github.com/NordicPlayground/fw-nrfconnect-nrf/tree/master/samples/usb/usb_uart_bridge

We unfortunately do not have a sample that combines usb_uart_bridge + hci_uart.

You can enable RTT logging on the nRF91 side, by setting this in your prj.conf:

CONFIG_USE_SEGGER_RTT=y

 

You should then be able to read the log output via segger rtt viewer.

 

Kind regards,

Håkon

[ArchDevel]

Håkon Alseth said:

We unfortunately do not have a sample that combines usb_uart_bridge + hci_uart.

Does this mean that we will not be able to utilize the lte_ble_gateway sample on the Thingy:91? I am utilizing the Thingy:91 and the Thingy:52 in a global asset tracking proof of concept for the smart energy sector. The hope is that I can transmit sensor data from a BLE device such as the Thingy:52, to a "Gateway," such as the Thingy:91 to be aggregated in the cloud. What are my options here if I cannot utilize this sample?

Håkon Alseth said:

You can enable RTT logging on the nRF91 side, by setting this in your prj.conf:

CONFIG_USE_SEGGER_RTT=y

Thank you, I will give this a try!

Kindest Regards,

Arch

[Håkon Alseth]

ArchDevel said:

Does this mean that we will not be able to utilize the lte_ble_gateway sample on the Thingy:91? I am utilizing the Thingy:91 and the Thingy:52 in a global asset tracking proof of concept for the smart energy sector. The hope is that I can transmit sensor data from a BLE device such as the Thingy:52, to a "Gateway," such as the Thingy:91 to be aggregated in the cloud. What are my options here if I cannot utilize this sample?

This means that we do not have a project that also handles USB->UART, while also handling hci_uart towards the nRF9160.

If you want to use the lte_ble_gateway + hci_uart on the thingy:91, there are a couple of gotcha's right now. These are shown (with fixes) here:

https://devzone.nordicsemi.com/f/nordic-q-a/52689/nrf9160-lte-sensor-gateway-on-thingy-91

 

Printing out debug info can still be done over RTT, but getting out the UART debug prints isn't in place when running lte_ble_gateway + hci_uart on the thingy:91.

 

Kind regards,

Håkon

[ArchDevel]

Thank you Håkon Alseth,

Thank you for directing me to that thread. I have followed what I could make of it and got the precompiled hex files loaded up. I have a few issues still but they seem to be pretty minor in nature and I am sure they are a result of me missing a step during the setup.

I have written a post in that thread asking Sigurd for a bit more clarification on the process that surrounds his thought process to see if we can surmise where I am missing the mark. 

Kindest Regards, 

Arch