Troubleshooting

This page has common problems and solutions for the nRF9151 Feather.

Power & Regulators

Enabling the 3.3V regulator output (NPM13xx)

The nRF9151 Feather uses an NPM13xx PMIC. To enable the 3.3V BUCK1 output, you need both Kconfig options and a devicetree overlay.

In your prj.conf:

# Regulator control
CONFIG_REGULATOR=y
CONFIG_REGULATOR_NPM13XX=y

In your board overlay (e.g. circuitdojo_feather_nrf9151.overlay):

&BUCK1 {
    // 3.3V
    regulator-min-microvolt = <3300000>;
};

Note: You may also reference the regulator using the full path (&i2c2 { … regulators { … BUCK1: … } }) or by its label if one is defined. After making changes, power-cycle the board for them to take effect.

Enabling device power management

If you need runtime power management (e.g. for sleep modes), add this to your prj.conf:

CONFIG_PM_DEVICE=y

Reading the NPM1300 reset cause

If your board is rebooting unexpectedly, you can read the NPM1300 PMIC's RSTCAUSE register to find out why. The register is at address 0x15 in the NPM1300's error log:

You can read this register via I2C using Zephyr's i2c_reg_read_byte() API targeting the NPM1300 device address.

Filesystem

LittleFS hangs with multiple open files

If your application hangs while writing to multiple files, check the following:

1. Increase the max open files limit. By default, LittleFS allows only 4 open files across all mounted filesystems:

   CONFIG_FS_LITTLEFS_NUM_FILES=8
   

2. Access the filesystem from a single thread. LittleFS operations are not inherently thread-safe. The same applies to peripheral access (I2C, SPI, etc.) — use a mutex or dedicate a single thread for filesystem I/O.

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.

HTTPS/TLS certificate errors

The nRF9151 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

1. Put the modem in offline mode:

   AT+CFUN=4
   

2. 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.
3. Verify it was stored:

   AT%CMNG=1
   

4. Return to normal mode:

   AT+CFUN=1
   

5. 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 nRF91x1 modem supports a limited set of ciphers including:

• 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.

Build Issues

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. Add these to your prj.conf to fix it:

CONFIG_TFM_SECURE_UART=n
CONFIG_TFM_LOG_LEVEL_SILENCE=y

Silencing TF-M log output

If TF-M log output is cluttering your serial console without causing a conflict, you can silence it alone with:

CONFIG_TFM_LOG_LEVEL_SILENCE=y

OTA / MCUBoot

Device reverts to old firmware after OTA update

If your device reverts to the previous firmware image after an OTA update, make sure your application calls:

boot_write_img_confirmed();

This confirms the new image with MCUBoot. Without this call, MCUBoot will revert to the previous image on the next reboot.