nRF9160 Feather - Suggestions for next version

@zpm1066 sure is. Two boards I built today program and blink. Still more to test though.

A video would be interesting. Stay tuned on that

As I alluded to earlier in the last post, a solution was needed to make sure the programmer is available even if you program something terribly bad to the board. In comes the recovery fixture:

Recovery Fixture

Currently, I was soldering wires to the SWD + GND pins on these boards to get direct programming access when the onboard programmer was inaccessible. I spent some time this morning creating a simple jig for recovering & programming any nRF916x Feather.

Here I have it powered up and running with an external PicoProbe.

Part Deux

While having a 3d printable fixture is handy, ultimately something in the firmware has to change. So, I changed the startup code that is built-in to the board definition to add a delay. This allows you to unplug, and then power on and access the onboard CMSIS DAP before the board shuts down the RP2040 circuit. I had removed this delay and that’s what got me into this whole sidequest in the first place.

Onwards

Alright. Now that’s out of the way back to validating these quiescent current issues!

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

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!

zpm1066 it should. Probably not a bad thing to check

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?