nRF9160 Feather - Suggestions for next version

zpm1066 · 2023-05-17T02:51:26+00:00

Hi Jared, Any chance you can share what new changes you have in mind for the next iteration of nRF9160 Feather? Although I do understand that board space i...

AchimKraus

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

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.

jaredwolff

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.

jaredwolff

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=y

To 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

jaredwolff

Adding documentation as we go:

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

AchimKraus

nRF9161-feather

nRF9161-feather in action

AchimKraus

What is the function of the button “BS”?

jaredwolff

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.

AchimKraus

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.

jaredwolff

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

AchimKraus

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.

jaredwolff

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?

AchimKraus

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

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

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.

AchimKraus

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.

AchimKraus

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” …

AchimKraus

About BUCK2, I guess it’s the RP2040.

jaredwolff

AchimKraus About BUCK2, I guess it’s the RP2040.

You are correct! It allows you to power down the RP2040 circuit when not using USB.

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

I would not switch it on-off dynamically. The nPM1300 is temperamental 😇 Can you explain your use case on this?

AchimKraus I currently updated the board-files for 2.6.1.

Commit a6d2546d82b16245d0e549cef68843390a34a8ca

Should be removed now in 1653032d49c20ff5927d584a0bb712509501c18c

AchimKraus

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.

AchimKraus

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.

« Previous Page Next Page »