Feather 9151's 3V3 is 2V7

marjonz

Why is the feather’s 3V3 (as per schematic) only outputting 2V7? Is there a software way to increase it to 3V3?

jaredwolff

marjonz It’s adjustable. Default is 2.7V as the parts on the board all support the lower voltage (some power savings here).

I believe if you put this in your overlay under the buck1 settings it should bring it up to 3.3 after boot:

regulator-init-microvolt = <3300000>;

The relevant area is:

		npm1300_regulators: regulators {
			compatible = "nordic,npm1300-regulator";

			npm1300_buck1: BUCK1 {
				regulator-min-microvolt = <2700000>;
				regulator-max-microvolt = <3300000>;
				regulator-init-microvolt = <3300000>;
				startup-delay-us = <2000>;
				regulator-always-on;
			};

			npm1300_buck2: BUCK2 {
				regulator-min-microvolt = <3300000>;
				regulator-max-microvolt = <3300000>;
			};


		};

marjonz

Thank you very much @jaredwolff , I will test this now.

marjonz

I spun off the circuitdojo_feather_nrf9151_ns_2.overlay file into my project, and put it under a board folder:
Looks like this now:

&i2c2 {

	sts4x: sts4x@44 {
		compatible = "sensirion,sts4x";
		reg = <0x44>;
		repeatability = <2>;
	};
};

npm1300_regulators: regulators {
	compatible = "nordic,npm1300-regulator";

	npm1300_buck1: BUCK1 {
		regulator-min-microvolt = <2700000>;
		regulator-max-microvolt = <3300000>;
		regulator-init-microvolt = <3300000>;
		startup-delay-us = <2000>;
		regulator-always-on;
	};

	npm1300_buck2: BUCK2 {
		regulator-min-microvolt = <3300000>;
		regulator-max-microvolt = <3300000>;
	};
};

But building a configuration for it, yields an error:

-- Found devicetree overlay: src/spidevice/spidevice.overlay
devicetree error: ./src/spidevice/spidevice.overlay:1 (column 1): parse error: expected '/' or label reference (&foo)
CMake Error at C:/nrf_workspace/mydevice/zephyr/cmake/modules/dts.cmake:305 (execute_process):
  execute_process failed command indexes:

    1: "Child return code: 1"

Call Stack (most recent call first):
  C:/nrf_workspace/mydevice/zephyr/cmake/modules/zephyr_default.cmake:133 (include)
  C:/nrf_workspace/mydevice/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
  C:/nrf_workspace/mydevice/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:92 (include_boilerplate)
  CMakeLists.txt:5 (find_package)


-- Configuring incomplete, errors occurred!
CMake Error at cmake/modules/sysbuild_extensions.cmake:514 (message):
  CMake configure failed for Zephyr project: mydevice

  Location: C:/nrf_workspace/mydevice/nfed/mydevice
Call Stack (most recent call first):
  cmake/modules/sysbuild_images.cmake:43 (ExternalZephyrProject_Cmake)
  cmake/modules/sysbuild_default.cmake:21 (include)
  C:/nrf_workspace/mydevice/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:75 (include)
  C:/nrf_workspace/mydevice/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:92 (include_boilerplate)
  C:/nrf_workspace/mydevice/zephyr/share/sysbuild-package/cmake/SysbuildConfig.cmake:8 (include)
  template/CMakeLists.txt:10 (find_package)


-- Configuring incomplete, errors occurred!
See also "C:/nrf_workspace/mydevice/nfed/mydevice/build/CMakeFiles/CMakeOutput.log".
←[91mFATAL ERROR: command exited with status 1: 'C:\ncs\toolchains\0b393f9e1b\opt\bin\cmake.EXE' -DWEST_PYTHON=C:/ncs/toolchains/0b393f9e1b/opt/bin/python.exe '-Bc:\nrf_workspace\mydevice\nfed\mydevice\build' -GNinja -DBOARD=circuitdojo_feather_nrf9151@1/nrf9151/ns -DCONF_FILE=prj.conf -DEXTRA_DTC_OVERLAY_FILE=src/spidevice/spidevice.overlay '-SC:\nrf_workspace\mydevice\zephyr\share\sysbuild' '-DAPP_DIR
:PATH=c:\nrf_workspace\mydevice\nfed\mydevice'
←[0m
 *  The terminal process terminated with exit code: 1. 
 *  Terminal will be reused by tasks, press any key to close it.

Sorry, but what am I doing wrong here?

marjonz

I got it compiling with these changes, my overlay:

&i2c2 {

	sts4x: sts4x@44 {
		compatible = "sensirion,sts4x";
		reg = <0x44>;
		repeatability = <2>;
	};
	
	npm1300: npm1300@6b {
        compatible = "nordic,npm1300";
        reg = <0x6b>;

        regulators {
            compatible = "nordic,npm1300-regulator";

            BUCK1: BUCK1 {
				regulator-min-microvolt = <2700000>;
				regulator-max-microvolt = <3300000>;
                regulator-init-microvolt = <3300000>; /* 3.3V */
				startup-delay-us = <2000>;
				regulator-always-on;
                // regulator-boot-on;
            };
            BUCK2: BUCK2 {
				regulator-min-microvolt = <3300000>;
				regulator-max-microvolt = <3300000>;
                regulator-boot-on;
            };
        };
    };
};

Looks like, per the schematic, both the sensirion and the npm1300 were on the same i2c lines anyway. Is this right?
I’m about to test it.

marjonz

It stayed at 2.7V though (rebooted the feather board)

AchimKraus

I use

&BUCK1 {
	// 3.3V
	regulator-min-microvolt = <3300000>;	
};

for that.
Note: you may use the paths as “&i2c2 { … regulators { … BUCK1: ” or, if a label (the part before the “:”) was assigned, that label at root scope with “&BUCK1”.
(And sometimes you need to remove the power, wait and connect it again for changes in the NPM1300.)

marjonz

Despite all the overlay changes, it seems the output of 3V3 is still staying at 2V7 🙁

jaredwolff

Did you enable the regulator in your config somewhere?

# Regulator control
CONFIG_REGULATOR=y
CONFIG_REGULATOR_NPM13XX=y

Changes to the .dts don’t mean anything unless the code is enabled to read & use it.

marjonz

jaredwolff It seems to not like the definition for CONFIG_REGULATOR_NPM13XX=y, It won’t build the configuration and fails.

Parsing C:/nrf_workspace/myproject/nfed/myproject/Kconfig
C:/nrf_workspace/myproject/nfed/myproject/prj.conf:56: warning: attempt to assign the value 'y' to the undefined symbol REGULATOR_NPM13XXLoaded configuration 'C:/nrf_workspace/myproject/nfed/boards/circu
itdojo/feather_nrf9151/circuitdojo_feather_nrf9151_ns_defconfig'
Merged configuration 'C:/nrf_workspace/myproject/nfed/myproject/prj.conf'
Merged configuration 'C:/nrf_workspace/myproject/nfed/myproject/build/myproject/zephyr/.config.sysbuild'

Where can I find the corresponding defines for the peripheral drivers please? Sorry for the ignorance.

marjonz

Seems like it just needed the :

# Regulator control
CONFIG_REGULATOR=y

Plus the overlay settings above and 3V3 is now showing. Thank you very much for the guidance.

jaredwolff

Before NCS 3.1 I believe it was CONFIG_REGULATOR_NPM1300

marjonz

jaredwolff I’m using 3.0.1, is there a place where all these defines could be found please? It’s not that helpful if Nordic keeps changing them and not having a place for the documentation. Or is that a feather thing, since not all boards will be fitted with this PMIC?

AchimKraus

marjonz It’s not that helpful if Nordic keeps changing them and not having a place for the documentation.

semantic versioning - why does a minor update frequently break the builds?

So, as Jared already wrote,

“Unless you need new features that they release it’s usually best to pick an SDK version and stick to it. ”

If you need assistance from Nordic, it may be required to the update to the latest NCS and provide modem traces. So I would recommend, to update the NCS from time to time, maybe if you have some more time in relaxed periods (if there some :-) ).

jaredwolff

@marjonz they change things for different reasons. Unless you need new features that they release it’s usually best to pick an SDK version and stick to it. Otherwise you have to pay the cost of jumping from version to version.

There’s some release-notes and migration-notes which are helpful in zephyr/doc/releases and nrf/doc/nrf/releases_and_maturity depending on where the code is located

marjonz

Thank you I will keep that in mind. Appreciate all the help with both this and all the other topics. I hope this thread and the others help other users.

marjonz

AchimKraus I agree with you both, I guess my bed was made with 3.0.2 then. 🙂
I don’t see an urgent need to upgrade to newer SDKs. Thank you for all the great advice.

I can’t find any “relaxed periods” as of yet, I’ve been flat out trying to get one function working after another. I have learnt a lot about nRF + Zephyr and the SDK.

I do get frustrated sometimes, as coming from baremetal and FreeRTOS background, I feel i could have done things faster. But again, this is the bed I am sleeping in now, so I need to be able to learn it.

I can’t thank you both enough. I am surprised at how much I can do with suck a small board. It’s been a love/hate relationship so far with the feather 9151. Starting to be more love than hate 😃

AchimKraus

By the way: if you need Nordic support, it is sometimes even better to also use their hardware. Therefore I try to have some (maybe limited) version of an app also running on a Nordic DK (e.g. nRF9151-DK). That makes it easier to provide modem traces and to exclude some specific hardware issues of custom boards.

AchimKraus

You’re welcome.

I can’t find any “relaxed periods” as of yet

In my case this takes sometimes 6 months and more to start working on updating. And it’s frequently time consuming and frustrating. But the good message is, if you not depend on updating “in time”, you may benefit from others struggles. Some new issues are then already solved and the support team at Nordic has already more experience with the new NCS than initially.