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.
nRF9160 Feather - Suggestions for next version
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.
- Edited
AchimKraus and so `zephyr/boards/arm/circuitdojo_feather_nrf9161/
deselects BOARD_CIRCUITDOJO_FEATHER_NRF9161_NS. In consequence,
Ahh OK.
I made some tweaks. If you want the PMIC init code you can add
CONFIG_CIRCUITDOJO_FEATHER_NRF9161_PMIC_STARTUP=yTo your .conf file in the application. 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.
I pushed the changes to your branch and 2.7.x
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_NSTo 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=nwith 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 statusI 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=ythat works as intended, if I remove
CONFIG_TFM_SECURE_UART=nSo, 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.
- Edited
The initial delay after flashing (it doesn’t occur after reset) is caused by a call to nrf_modem_lib_shutdown. Not sure, what is delaying there.
Edited: I cleaned up my startup and the delay is gone.
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=ytherefore 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.
pyocd reset --target nRF9160_xxAA
0001508 W nRF9160_xxAA APPROTECT enabled: will try to unlock via mass erase [target_nRF91]
0002286 W Skipping CoreSight discovery for AHB-AP#1 because it is disabled [ap]The (randomly occurring) “mass erase” now occurred the first time just for “reset” …
About BUCK2, I guess it’s the RP2040.
- Edited
I’ve been testing with NPM1300 events.
I assume, this requires to “connect an output of the npm1300 to an gpio interrupt input of the nRF9161”. That’s missing.
Switching the RP2040/BUCK2 dynamically on/off seems to cause more pain. At least my first tests haven’t been successful. For now, I simplified it for my demo-client to detect USB on startup and disable the BUCK2, if USB is not detected.