nRF9160 Feather - Suggestions for next version

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

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.

I currently pushed my experimental support for the nRF9161-feather to my coaps-client into the “extra” folder.

Many issue could be solved, the main left pain is for me the “random mass erase”, which happens in my experience only with that RP2040 OCD.
And maybe one improvement would be, if plugin USB and the RP2040 could be combined. I wasn’t able to start the RP2040 later, not to disable it later. Therefore I stick to a solution doing that “switch” only on startup.

I currently updated the board-files for 2.6.1.

Commit a6d2546d82b16245d0e549cef68843390a34a8ca

The

# Fixes for I2C
CONFIG_TFM_SECURE_UART=n
CONFIG_TFM_LOG_LEVEL_SILENCE=y

circuitdojo_feather_nrf9161_ns_defconfig

is still there.

For the reset issue, it may be related to this:

https://github.com/pyocd/pyOCD/issues/1576

I did not connect the nRST to the RP2040. I’ll have to do that next!

For keeping the RP2040 powered on USB removal you do need to enable GPIO0 on the nPM1300 or else, yes you will have issues as well:

Can you explain your use case on this?

If USB is plugged in, I don’t care about the power consumption. But if I remove it, I would like to power down the RP2040 and so the BUCK2. That didn’t work, at least not in my tests so far.

If USB is not plugged in, and I don’t disable BUCK2, my quiescent current is about 800µA (or so).
If USB is not plugged in, and I disable BUCK2, my quiescent current is about 25µA (or so).

But if I disable BUCK2 and plugin USB for logging, that doesn’t work. If I power the RP204 again switching on BUCK2, it doesn’t work either, at least not in my tests so far.

So my idea is simple:
If USB is plugged, even in a running device, I would like to have logging.
If USB is unplugged, even from a running device, I would like to have the 25µA.

As I wrote: For now I just detect that at the boot time. That will also work for me. But a dynamic solution in the future would be more, what I consider others to expect.

For keeping the RP2040 powered on USB removal you do need to enable GPIO0 on the nPM1300 or else, yes you will have issues as well:

No, I want to remove power from the RP2040 on USB removal. But in my case, this doesn’t result in 25µA. I remember even 5mA.

AchimKraus If USB is plugged in, I don’t care about the power consumption. But if I remove it, I would like to power down the RP2040 and so the BUCK2. That didn’t work, at least not in my tests so far.

Did you take a look at the active_sleep sample? I do all the necessary switching there.

The RP2040 is partially forced on when USB is attached. You still need to enable BUCK2 if it was disabled earlier.

AchimKraus So my idea is simple:
If USB is plugged, even in a running device, I would like to have logging.
If USB is unplugged, even from a running device, I would like to have the 25µA.

Yup! That makes sense. You’ll need to manage the power supply for the RP2040 manually. I’ll be adding the interrupt pin so you can know when USB is inserted and make the necessary changes to the nPM1300 to power on the USB domain parts.

AchimKraus As I wrote: For now I just detect that at the boot time. That will also work for me. But a dynamic solution in the future would be more, what I consider others to expect.

Yup! I fear that you would not be the only person to expect this since it was something you could do with the other board. Maybe I’ll have a small routine as part of startup.c that will manage the power supply functionality for you when USB is inserted/removed.

You will likely have to look at the v2.7.x version since 2.6.x didn’t get the updates:

https://github.com/circuitdojo/nrf9160-feather-examples-and-drivers/tree/v2.7.x/samples/active_sleep