nRF9160 Feather - Suggestions for next version

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.

After flashing it seems to require an hw reset by the button, otherwise the modem seems to be inaccessible.

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

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

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.

I was thinking in comparison with the non-modem samples

The it could be switched off in the prj.conf of that samples.
in general I would try to use defaults, which works for the most cases. And then just give advice how to optimize that in special cases. For me, using the modem is the general case. And the other the special case.

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

I think originally I was using I2C1 but moved it to I2C2. That way someone could easily do a modem trace without having to re-map their peripherals. I removed those items from defconfig and no longer get build issues. I’m assuming you’re using UART1/I2C1/SPI1?

Looks like it’s only enabled when UART1 pins are mapped:

config TFM_SECURE_UART
	bool "TF-M configure UART instance as secure peripheral"
	default y if !TFM_LOG_LEVEL_SILENCE
	help
	  Configure the UART instance as a secure peripheral for TF-M logging.
	  This makes the UART instance unavailable to the non-secure unless
	  TFM_SECURE_UART_SHARE_INSTANCE is enabled.
	  When this option is selected the device tree node for
	  the UART instance needs to be disabled for the non-secure application.

config TFM_LOG_LEVEL_SILENCE
	default y if !$(dt_nodelabel_has_prop,uart1,pinctrl-names)
	help
	  Disable TF-M secure output if the uart1 node has not assigned GPIO
	  pins using pinctrl.

AchimKraus CONFIG_TFM_SECURE_UART_SHARE_INSTANCE=y
CONFIG_TFM_SECURE_UART0=y

Would it make sense to put these in the defconfig?

I think originally I was using I2C1 but moved it to I2C2. That way someone could easily do a modem trace without having to re-map their peripherals. I removed those items from defconfig and no longer get build issues.

Great!

I’m assuming you’re using UART1/I2C1/SPI1?

I’m using

CONFIG_TFM_SECURE_UART_SHARE_INSTANCE=y
CONFIG_TFM_SECURE_UART0=y

therefore I was mixed up by the error message “undefined reference to `Driver_USART1′”, because my conf should use SUART0.

Would it make sense to put these in the defconfig?

Not sure about that. There may be some security consideration. Therefore I think, that using logging in TF-M is something, everyone should decide on its own and then config it accordingly to that decision.

What’s the purpose of BUCK2?

If enabled, the quiescent current is about 800µA. If disabled (as in “sample/active_sleep”) it’s about 25µA.