nRF9160 Feather - Suggestions for next version

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.

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

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?

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.

Thanks for the explanation.

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:

1. 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.
2. 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!

JS110

PPK2 doesn’t sample as fast.

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

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