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

        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.

            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.

                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

                      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.

                                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,
                             &reg);
  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.

                                      Terms and Conditions | Privacy Policy