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
In particular:
static int setup_pmic()
{
#if defined(CONFIG_BOARD_CIRCUITDOJO_FEATHER_NRF9161)
int err;
/* Get pmic */
static const struct device *pmic = DEVICE_DT_GET(DT_NODELABEL(npm1300_pmic));
if (!pmic)
{
LOG_ERR("Failed to get PMIC device\n");
return -ENODEV;
}
/* Disable if not already disabled */
if (regulator_is_enabled(buck2))
{
err = regulator_disable(buck2);
if (err < 0)
{
LOG_ERR("Failed to disable buck2: %d", err);
return err;
}
}
uint8_t reg = 0;
/* See if pulldown is not already enabled */
err = mfd_npm1300_reg_read(pmic, NPM1300_BUCK_BASE, NPM1300_BUCK_BUCKCTRL0,
®);
if (err < 0)
LOG_ERR("Failed to set VBUSINLIM. Err: %d", err);
if ((reg & (NPM1300_BUCK2_PULLDOWN_EN)) == 0)
{
/* Write to MFD to enable pulldown for BUCK2 */
err = mfd_npm1300_reg_write(pmic, NPM1300_BUCK_BASE, NPM1300_BUCK_BUCKCTRL0,
NPM1300_BUCK2_PULLDOWN_EN);
if (err < 0)
LOG_ERR("Failed to set VBUSINLIM. Err: %d", err);
}
#endif
return 0;
}Putting the flash chip in DPD and also disabling the UART receiver also needs to be done. Also when programming the device will remain in high current (5mA) and you will need to reset the board in order to disable the SWD hardware internally to the nRF91 (may require a power cycle let me check)
Did you take a look at the active_sleep sample? I do all the necessary switching there.
sure. it’s static, isn’t it?
I do the same in my power_manager. That check on startup for USB and disables/enables BUCK2 accordingly.
But only on startup. Disable or enable BUCK2 later didn’t work that good in my tests.
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.
Exactly.
It’s something I would like to have in the future. For now I’m happy with it.
@AchimKraus if you can replicate how to cause pyocd to see AppProtect enabled please let me know. It happens here occasionally but I haven’t seen it consistently enough.
feather-tester-software on main [$!?⇡] via 
v3.10.12 (env) via 
v1.80.0 took 10s
❯ pyocd load --target nRF9160_xxAA --format hex _bin/v5-2-ga33aa1f-fast-blink.hex
0000859 W Skipping CoreSight discovery for AHB-AP#1 because it is disabled [ap]
0000897 I Loading /home/jaredwolff/Git/feather-tester-software/_bin/v5-2-ga33aa1f-fast-blink.hex [load_cmd]
[==================================================] 100%
0004822 I Erased 0 bytes (0 sectors), programmed 0 bytes (0 pages), skipped 176128 bytes (43 pages) at 44.60 kB/s [loader]
feather-tester-software on main [$!?⇡] via v3.10.12 (env) via v1.80.0 took 9s
❯ pyocd reset --target nrf9160_xxaa
0000849 W Skipping CoreSight discovery for AHB-AP#1 because it is disabled [ap]
feather-tester-software on main [$!?⇡] via v3.10.12 (env) via v1.80.0 took 6s
❯ pyocd load --target nRF9160_xxAA --format hex _bin/v5-2-ga33aa1f-fast-blink.hex
0000858 W Skipping CoreSight discovery for AHB-AP#1 because it is disabled [ap]
0000896 I Loading /home/jaredwolff/Git/feather-tester-software/_bin/v5-2-ga33aa1f-fast-blink.hex [load_cmd]
[==================================================] 100%
0004812 I Erased 0 bytes (0 sectors), programmed 0 bytes (0 pages), skipped 176128 bytes (43 pages) at 44.70 kB/s [loader]One other option is to use probe-rs instead. I’m currently testing transitioning it fully for factory test/programming. I just ported over the MFW upgrade procedure to Rust as well and it seems to be working OK. 
jaredwolff if you can replicate how to cause pyocd to see AppProtect enabled please let me know
Unfortunately, I don’t know how to reproduce it. Sometimes I believed, it depends on other USB device plugged in and out. But that doesn’t verify. I would guess, it’s an timing issue in the pycod software and the timeout is interpreted in that way.
One issue I found:
dfu seems to be broken, at least in my case ;-).
A call to boot_erase_img_bank ends up in an exception and reboot.
Is there already a tested sample? If not, that for short term no issue.
But in mid-term I consider dfu as mandatory.
AchimKraus DFU shouldn’t be any different from the nRF9160. It’s possible that the partition management side is not configured correctly.
You may need these guys set to make sure you’re not using external NOR flash:
# Do not use external flash for secondary
CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=n
CONFIG_PM_PARTITION_REGION_LITTLEFS_EXTERNAL=y
CONFIG_PM_PARTITION_SIZE_LITTLEFS=0x400000
CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=yFor me, zephyr or NCS seems to be fragile for switching static and dynamic pm-partitions. I prefer to use the static pm defined ny Nordic for the Thingy:91. That works for nRF9160 (thingy:91, dk, feather, mikroe) and nRF9161 (so far only for the dk).
I will try your configs, but “CONFIG_PM_PARTITION_SIZE_LITTLEFS” smeels for me to inhibit switching the pm-partitions.
Great, using
CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=nalready does the trick.
“nrf/subsys/partition_manager/Kconfig”:
config PM_EXTERNAL_FLASH_ENABLED
bool
default $(dt_chosen_enabled,$(DT_CHOSEN_EXT_FLASH))
help
Internal PM_EXTERNAL_FLASH kconfig for exporting devicetree to sysbuild.seems, that this trigger the usage of the external flash. (Even if for now, I don’t see, where that chose is defined).
edited:
get it
AchimKraus I will try your configs, but “CONFIG_PM_PARTITION_SIZE_LITTLEFS” smeels for me to inhibit switching the pm-partitions.
Yup that’s fine. I put them all in there. That’s actually the settings for the nRF9160 Feather not the new board.
Glad you got it going!
For the curious you’ll need a pm_static.yml entry
littlefs_storage:
address: 0x0
region: external_flash
size: 0x400000New versions of NFED will include pre-defined pm_static.yml controlled by CONFIG_CIRCUITDOJO_FEATHER_NRF9160_STATIC_PARTITIONS_FACTORY which can be disabled. Since that was being sent, pm_static.yml inside the app wasn’t being applied. I’ll have to adjust this for the nRF91×1 as well.
Adjusted for file size. These config entries
# SPI Flash
CONFIG_SPI=y
CONFIG_SPI_NOR=y
CONFIG_SPI_NOR_FLASH_LAYOUT_PAGE_SIZE=4096
CONFIG_SPI_NOR_SFDP_RUNTIME=y
# Enable flash operations.
CONFIG_FLASH=y
CONFIG_FLASH_MAP=y
CONFIG_FLASH_PAGE_LAYOUT=y
# Enable the LittleFS file system.
CONFIG_FILE_SYSTEM=y
CONFIG_FILE_SYSTEM_LITTLEFS=y
# Partition manager settings
CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=n
CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=yOkkk!
Sorry for the lack of updates. I’ve been waiting for boards plus orders have been keeping Circuit Dojo HQ busy.
I digress. I mentioned this guy before but the first rev had some issues. A batch of the second version is built and ready to go.
It works with all Circuit Dojo Feather boards. (nRF91xx, nRF52833 (unreleased), etc) and supports use of the Raspberry Pi Debug Probe and 10-pin Segger JLink interface. I even went the extra step to bring out the reset pin for the 10-pin 
Here’s the bottom:
I imagine this would be good for mass programming and also de-borking boards if you do something silly.
The design will be open sourced at the launch of the nRF91×1 Feather. I’ll have more on that shortly. For those folks who are looking for early samples I should have some this week as long as assembly & testing works out OK.
Great news. How can it be ordered?
Just to mention:
The nRF9161 feather (beta) board shipped in August works pretty well. Stable online now for more than 30days.
AchimKraus Awesome. Stay tuned on that front.
Lots going on here! I’m working on updating my test fixtures as an all-in-one. The first step is to transition the 1-up fixture and then the 9 up fixture.
I’m also just about ready to send boards over for RF testing. I will also have more boards for more beta/field testing. So for those who reached out to me, I haven’t forgotten about you.
More very soon.
Things are coming together with the all-in-one 1-up tester.
It looks like what I designed which is a plus . It will do all testing that I was previously doing across 3 test stations.
I also have some other news regarding the new board. Since the nRF9151 is fresh off the production line I decided to modify the nRF9161 Design to accommodate the new SiP.
It has the same features and functionality of the original design plus some room to grow as Nordic continues to develop on the platform. A few should be going out for FCC/CE next week if all goes well. The rest will be up for grabs once the tester is 100%.
jaredwolff
Fantastic! I was going to suggest the same, i.e. replace nRF9161 with a nRF9151. The latter now being Nordic Semi’s preferred recommendation for all new nRF91 designs. More real estate for you to add components , for example - accelerometers and microphone for Edge AI or a 10-pin mini-SWD connecter.
The new test fixture looks impressive. A significant boost to your testing.
btw - I’ve been field testing nRF9131-EK for DECT NR+ and LTE-M/NB-IoT with GNSS. A very neat board, slightly longer than a Sparkfun Thing+ board, with nPM1300, nPM600, 256Mb external flash memory, and a Segger J-link OB. There are a few more enhancements coming down the line to make it even better.
