Troubleshooting

This page has a list of common problems and solutions realated to the nRF9160 Feather.

Compiling Problems

Getting a `west.manifest.ManifestImportFailed` when building on Mac

Make sure that you've installed Xcode Command Line tools using xcode-select --install

Programming problems

The nRF9160 Feather does nothing after being programmed/flashed.

After being programmed using west flash, you may have to issue an additional nrfjprog -r or hit the RST button on the board. This should start code execution.

If your nRF9160 Feather is plugged into USB, try a different USB power supply. During the testing of the nRF9160 Feather, I found that certain USB C-to-A adapters injected were not properly grounded. This lead to issues getting a fix or prevented it all together. This especially applied to Apple Macbooks.

"The toolchain is unable to build a dummy C file"

If you're trying to build an example and you're getting an error building your code your should delete the Cmake cache:

rm -rf ~/Library/Caches/zephyr

This error typically occurs when the Zephyr CMake cache has become stale or corrupted. Deleting the cache forces the build system to re-detect your toolchain on the next build.

Also see this community thread for additional context.

Debugging a Hard Fault

[00:00:07.098,754] <err> os: Exception occurred in Secure State
[00:00:07.105,346] <err> os: ***** HARD FAULT *****
[00:00:07.110,961] <err> os:   Fault escalation (see below)
[00:00:07.117,279] <err> os: ***** BUS FAULT *****
[00:00:07.122,833] <err> os:   Precise data bus error
[00:00:07.128,601] <err> os:   BFAR Address: 0x50008158
[00:00:07.134,582] <err> os: r0/a1:  0x00000000  r1/a2:  0x20021489  r2/a3:  0x20021490
[00:00:07.143,341] <err> os: r3/a4:  0xffffffff r12/ip:  0x00046f95 r14/lr:  0x0003ba81
[00:00:07.152,130] <err> os:  xpsr:  0x81000000
[00:00:07.157,379] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
[00:00:07.167,938] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00:00:07.178,466] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
[00:00:07.188,995] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
[00:00:07.199,523] <err> os: fpscr:  0x00000000
[00:00:07.204,772] <err> os: Faulting instruction address (r15/pc): 0x00047ba0
[00:00:07.212,768] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:07.220,672] <err> os: Current thread: 0x20017d00 (unknown)

$ /opt/nordic/ncs/v1.5.0/toolchain/bin/arm-none-eabi-addr2line -e build/zephyr/zephyr.elf 0x00047ba0
reent.c:?

`Error 3` from `newtmgr`

While programming via newtmgr you may run into problems programming your board via the bootloader:

newtmgr -c serial image upload build/zephyr/app_update.bin
63.70 KiB / 65.69 KiB [===================================================================================================================================================================================>-----]  96.98% 15.82 KiB/s
Error: 3

There are a few reasons for this incuding:

Make sure that you do not have your serial console open while transferring. This will case some data to drop during the application upgrade.
V1 versions of the nRF9160 Feather only work with older versions of the SDK (1.2.x ad 1.3.x). The solution here is to upgrade the bootloader.
- Navigate to the downloads page and download the V2 bootloader
- Attach your programming cable and board as you would in programming and debugging
- Use nrfjprog (or similar) to load the file:
```
nrfjprog --program bootloader.hex --chiperase
```
Alternatively you can also downgrade SDK version but this is not supported.
For V1 bootloaders, newtmgr will not program images above 196kB. The solution here is to upgrade to the latest bootloader.

I2C stops working after upgrading to SDK 2.6.0 or later

SDK 2.6.0 enabled TF-M (Trusted Firmware-M) logging by default over UART1, which conflicts with I2C1 on the nRF9160 Feather. Add these to your prj.conf to fix it:

CONFIG_TFM_SECURE_UART=n
CONFIG_TFM_LOG_LEVEL_SILENCE=y

Cellular Connectivity

First connection takes a long time

If you have a freshly provisioned SIM, the first connection can take several minutes while the carrier provisions and propagates your device. This is normal. Subsequent connections will be faster.

Connection refused (`-111`) when connecting to an external server

If you're getting Unable to connect. Err: -111 - Connection refused when using sockets:

Verify the PDP context is configured correctly for your carrier. See the Cellular Provider Matrix for the correct APN settings.
Check that your server is reachable from the cellular network. Some servers may block connections from cellular IP ranges.
For TLS/HTTPS connections, make sure you've loaded the correct root CA certificate into the modem's secure key store (see below).

HTTPS/TLS certificate errors

The nRF9160 modem has its own TLS stack and secure key store. To connect to an HTTPS server, you must provision the server's root CA certificate into the modem.

Loading certificates via AT commands

Put the modem in offline mode:
```
AT+CFUN=4
```
Write the root CA certificate to a security tag of your choosing (e.g. tag 42):
```
AT%CMNG=0,42,0,"-----BEGIN CERTIFICATE-----
<certificate content>
-----END CERTIFICATE-----"
```
Where the credential types are: 0 = Root CA, 1 = Client cert, 2 = Client private key.
Verify it was stored:
```
AT%CMNG=1
```
Return to normal mode:
```
AT+CFUN=1
```
In your application code, use the same security tag when setting up the TLS socket.

Note: Some modem firmware versions (e.g. 2.0.2) have issues with AT%CMNG commands, returning CME ERROR 527. If you encounter this, try downgrading to modem firmware 2.0.0 or upgrading to a newer release.

Cipher compatibility

Some servers (notably Azure) only accept specific TLS cipher suites. The nRF9160 modem supports the following cipher suites:

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

If your server requires a cipher not in this list, consider placing a TLS-terminating proxy (e.g. Caddy, nginx) in front of your endpoint.

Still not working?

Get a modem trace to see exactly what's happening at the TLS layer. See the Getting a modem trace section for instructions.