nRF9160 Feather - Suggestions for next version

JS110

PPK2 doesn’t sample as fast.

Some first experience:

Using west flash --runner pyocd sometimes reports

W nRF9160_xxAA APPROTECT enabled: will try to unlock via mass erase [target_nRF91]

not sure, what’s causing that. The “mass erase” will erase the “settings”.
After flashing it seems to require an hw reset by the button, otherwise the modem seems to be inaccessible.

Beside of that the nRF9161 feather works very nice!
Using the LEDs isn’t to complicated and in addition to the nRF9160 feather it’s now possible to read the charger status.
I’m not sure, why Nordic decided to not implement the zephyr “charger API”, and to use the “npm1300 sensor” API requires some datasheet reading. But all in all, my client was fast ported and we will see, how long that new feather will run on battery ;-).

Changes required:
The

		button0: button_0 {
			gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
			label = "Switch 1";
			zephyr,code = <INPUT_KEY_0>;
		};

seems to use the wrong polarity, I changed it to GPIO_ACTIVE_HIGH

About the power rails:
Is VDD connected to the battery or to the NPM1300?
Or in other words, does “AT%XVBAT” report the battery voltage or the output voltage of the NPM1300?

AchimKraus not sure, what’s causing that. The “mass erase” will erase the “settings”.
After flashing it seems to require an hw reset by the button, otherwise the modem seems to be inaccessible.

Not quite sure. It may be that pyocd is enabling the write protect. I haven’t had enough time to look at it.

AchimKraus Using the LEDs isn’t to complicated and in addition to the nRF9160 feather it’s now possible to read the charger status.
I’m not sure, why Nordic decided to not implement the zephyr “charger API”, and to use the “npm1300 sensor” API requires some datasheet reading. But all in all, my client was fast ported and we will see, how long that new feather will run on battery ;-).

Glad it’s working.

AchimKraus seems to use the wrong polarity, I changed it to GPIO_ACTIVE_HIGH

Yup you’re correct. Changed.

AchimKraus About the power rails:
Is VDD connected to the battery or to the NPM1300?
Or in other words, does “AT%XVBAT” report the battery voltage or the output voltage of the NPM1300?

VDD is hooked to VSYS which is whatever is providing the power (battery or USB). The VBAT command will measure the battery unless you have USB plugged in (then it will read 5V)

I’m still on v2.6.1.

One additional irritating issue is, that it fails to build, if CONFIG_TFM_LOG_LEVEL_SILENCE=n is used. That works at least for nRF9161-DK.

AchimKraus It gets sometimes delayed for 50s. For now I guess, that’s the “secure random”. That will require some more investigation.

50s! Wow it’s not taking that long here. That’s definitely an issue.

Adding documentation as we go:

https://docs.circuitdojo.com/nrf91x1-feather/building-and-programming.html

What is the function of the button “BS”?

AchimKraus What is the function of the button “BS”?

It’s not what you think!

It’s the boot select button for the RP2040. Hold it while plugging in and it will put the RP2040 into bootloader mode.

About the updated board-support:

I would prefer to add a default, e.g.

config CIRCUITDOJO_FEATHER_NRF9161_PMIC_STARTUP
	bool "Allows for executing startup code for PMIC."
	default y if BOARD_CIRCUITDOJO_FEATHER_NRF9161_NS

To be frank, “It’s only necessary for samples that use lots of current (i.e. anything that uses the modem). Otherwise it will remain off for everything.” will not apply to often. If I don’t need the modem, there are much cheaper and more powerful feathers. Therefore I guess it’s usually on, and only in some rare cases it may be off.

@AchimKraus understood! I was thinking in comparison with the non-modem samples. But yep, it doesn’t hurt to have it on at all times. My biggest hurdle it making sure that it’s only loaded in the app image and nothing else since it also includes a 2 second delay for device recovery purposes.

circuitdojo_feather_nrf9161_ns_defconfig.

# Fixes for I2C
CONFIG_TFM_SECURE_UART=n

with that I get:

modules/tee/tf-m/trusted-firmware-m/platform/ext/common/uart_stdout.c:104: undefined reference to `Driver_USART1'
Memory region         Used Size  Region Size  %age Used
           FLASH:       47932 B      48640 B     98.54%
             RAM:       14244 B        32 KB     43.47%
collect2: error: ld returned 1 exit status

I guess, that is considered for i2c1 (which was used for the nRF9160 but not for nRF9161, there it’s i2c2) and the default TF-M UART1. I use

CONFIG_TFM_SECURE_UART_SHARE_INSTANCE=y
CONFIG_TFM_SECURE_UART0=y

that works as intended, if I remove

CONFIG_TFM_SECURE_UART=n

So, do you think, this is required in general? What is the benefit of that?
If it should be kept, I will just enable it again on my own “risk” in the prf.conf.