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

JeppeMariagerLam

Awesome updates Jared! Thank you for all the hard work!! I look forward to testing it when you feel ready! 🙂

jaredwolff

AchimKraus One of the most repeated critical point of the old design was the TC2030-CTX-NL instead of a 10 pin header.
Now it turns into something else, you even can’t buy, or? Let’s see, which feedback that gets in the future.

@AchimKraus what can’t you buy? I’ll likely open source and make this little jig available for customers to buy as well if there’s interest. It’s definitely handy for programming many boards but not required.

Overall, the idea is to avoid this since the onboard RP2040 does everything that you’d expect (except for RTT). Since there’s a dedicated console UART I figured that final point wasn’t a big deal.

I do appreciate your feedback about the 10 pin. It simply doesn’t fit on this design and is 4x the cost of the RP2040 circuit. As you alluded, we’ll see how it goes. 😃

zpm1066 After using the solder paste on the stencil, did you use a digital microscope and a fine hot air gun to assist with soldering the SMDs?

I do have a microscope (analog one I bought a looooong time ago) for inspection. But I do use a small reflow oven and appropriate ventilation equipment. Previously I was using one of those plug-in skillets but that got old fast (and don’t work for both sides!)

JeppeMariagerLam Awesome updates Jared! Thank you for all the hard work!! I look forward to testing it when you feel ready! 🙂

Thanks Jeppe 🙂

AchimKraus

To be frank:
One of the most repeated critical point of the old design was the TC2030-CTX-NL instead of a 10 pin header.
Now it turns into something else, you even can’t buy, or? Let’s see, which feedback that gets in the future.

zpm1066

jaredwolff Nice work!
After using the solder paste on the stencil, did you use a digital microscope and a fine hot air gun to assist with soldering the SMDs?

zpm1066

jaredwolff I do have a microscope (analog one I bought a looooong time ago) for inspection. But I do use a small reflow oven and appropriate ventilation equipment. Previously I was using one of those plug-in skillets but that got old fast (and don’t work for both sides!)

Currently hand solder the SMDs but may look for an inexpensive small reflow oven down the line.

btw - Neat 3D printed jig with the pogo pins.

AchimKraus

what can’t you buy?

The orange jig.

I’ll likely open source and make this little jig available for customers to buy as well if there’s interest.

Nice.

It’s definitely handy for programming many boards but not required.

Maybe it’s not clear, when it gets required. Is it used to flash the RP2040? Or the nRF9161?

jaredwolff

AchimKraus

AchimKraus Maybe it’s not clear, when it gets required. Is it used to flash the RP2040? Or the nRF9161?

Flash the nRF91 in rare situations (like disabling the boot delay in the startup code). Othwerwise the built in RP2040 should do it. The Rp2040 has an immutable USB bootloader so if you ever want to upgrade the CMSIS DAP or run your own code you can do that too.

AchimKraus

Thanks for the explanation.

jaredwolff

Progress!

Right now the active sleep current is much better thanks to some input from Nordic. Turns out two issues affecting the NOR flash were affecting the current usage:

While Idle in DPD was enabled, newer version of NCS/Zephyr it was not putting the flash in DPD. Easily fixed by forcing the flash to sleep using power management.
The timing parameters were a bit off which would explain why over restarts I was getting different current values.

I do see the active sleep creep up over time and I think that’s due to some leakage from the SWD lines (one stays high at all times) and the RP2040. That will be fixed in the next round of boards.

Finally, it feels like I’m making progress!

zpm1066

jaredwolff Are you using a Joulescope JS110 or JS220 analyzer?
Wouldn’t the Nordic Power Profiler Kit II II do similar measurements? Thanks.

jaredwolff

Qwiic is also 👍️

Connected to /dev/ttyACM0!
[00:00:00.255,554] <dbg> BME280: bme280_chip_init: ID OK
[00:00:00.265,991] <dbg> BME280: bme280_chip_init: "BME280" OK
[00:00:00.267,822] <inf> lis2dh: fs=2, odr=0x4 lp_en=0x0 scale=9576
*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
*** Vsys Current Limit: 500 mA ***
Found device "BME280"
temp: 22.840000; press: 101.012050; humidity: 53.820312
temp: 23.010000; press: 101.010917; humidity: 53.737304

zpm1066

jaredwolff Nice!

Does the AQW board work with nRF9161 Feather? Thanks.

jaredwolff

zpm1066 it should. Probably not a bad thing to check 😉

jaredwolff

JS110

PPK2 doesn’t sample as fast.

AchimKraus

Maybe someone can jump in.
I’m currently struggling to build apps for the new nRF9161 feather.
As “usual”
it builds on Jared’s machine
it fails on my machine.

if someone could spend an hour or so, it would be great, if you can check that on your machine .-).

See other ticket “builds for nRF9161 with mcuboot” for some more details

AchimKraus

Some first experience:

Using west flash --runner pyocd sometimes reports

W nRF9160_xxAA APPROTECT enabled: will try to unlock via mass erase [target_nRF91]

not sure, what’s causing that. The “mass erase” will erase the “settings”.
After flashing it seems to require an hw reset by the button, otherwise the modem seems to be inaccessible.

Beside of that the nRF9161 feather works very nice!
Using the LEDs isn’t to complicated and in addition to the nRF9160 feather it’s now possible to read the charger status.
I’m not sure, why Nordic decided to not implement the zephyr “charger API”, and to use the “npm1300 sensor” API requires some datasheet reading. But all in all, my client was fast ported and we will see, how long that new feather will run on battery ;-).

Changes required:
The

		button0: button_0 {
			gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
			label = "Switch 1";
			zephyr,code = <INPUT_KEY_0>;
		};

seems to use the wrong polarity, I changed it to GPIO_ACTIVE_HIGH

jaredwolff

AchimKraus not sure, what’s causing that. The “mass erase” will erase the “settings”.
After flashing it seems to require an hw reset by the button, otherwise the modem seems to be inaccessible.

Not quite sure. It may be that pyocd is enabling the write protect. I haven’t had enough time to look at it.

AchimKraus Using the LEDs isn’t to complicated and in addition to the nRF9160 feather it’s now possible to read the charger status.
I’m not sure, why Nordic decided to not implement the zephyr “charger API”, and to use the “npm1300 sensor” API requires some datasheet reading. But all in all, my client was fast ported and we will see, how long that new feather will run on battery ;-).

Glad it’s working. 🙂

AchimKraus seems to use the wrong polarity, I changed it to GPIO_ACTIVE_HIGH

Yup you’re correct. Changed.

AchimKraus About the power rails:
Is VDD connected to the battery or to the NPM1300?
Or in other words, does “AT%XVBAT” report the battery voltage or the output voltage of the NPM1300?

VDD is hooked to VSYS which is whatever is providing the power (battery or USB). The VBAT command will measure the battery unless you have USB plugged in (then it will read 5V)

AchimKraus

And CONFIG_BOARD is undefined. Not sure, why.

I’ve added

if BOARD_CIRCUITDOJO_FEATHER_NRF9161_PMIC_STARTUP

config BOARD
	default "circuitdojo_feather_nrf9161"

endif

as temporary work-around to Kconfig.defconfig.

AchimKraus

About the power rails:
Is VDD connected to the battery or to the NPM1300?
Or in other words, does “AT%XVBAT” report the battery voltage or the output voltage of the NPM1300?

AchimKraus

About the CONFIG_BOARD:

in “zephyr/boards/Kconfig”

choice
	prompt "Board Selection"

source "$(BOARD_DIR)/Kconfig.board"

endchoice

That makes a choice out of `zephyr/boards/arm/circuitdojo_feather_nrf9161/Kconfig.board’

if SOC_NRF9161_LACA

config BOARD_CIRCUITDOJO_FEATHER_NRF9161
	bool "Circuit Dojo nRF9161 Feather"

config BOARD_CIRCUITDOJO_FEATHER_NRF9161_NS
	bool "Circuit Dojo nRF9161 Feather non-secure"

config BOARD_CIRCUITDOJO_FEATHER_NRF9161_PMIC_STARTUP
	bool "Allows for executing startup code for PMIC."

endif # SOC_NRF9161_LACA

and so `zephyr/boards/arm/circuitdojo_feather_nrf9161/circuitdojo_feather_nrf9161_ns_defconfig’

# Startup code
CONFIG_BOARD_CIRCUITDOJO_FEATHER_NRF9161_PMIC_STARTUP=y

deselects BOARD_CIRCUITDOJO_FEATHER_NRF9161_NS. In consequence,

if BOARD_CIRCUITDOJO_FEATHER_NRF9161 || BOARD_CIRCUITDOJO_FEATHER_NRF9161_NS

config BOARD
	default "circuitdojo_feather_nrf9161"

is not longer applied.

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

« Previous Page Next Page »