nRF9160 Feather - Suggestions for next version

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.

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.

One issue I found:
dfu seems to be broken, at least in my case ;-).

A call to boot_erase_img_bank ends up in an exception and reboot.
Is there already a tested sample? If not, that for short term no issue.
But in mid-term I consider dfu as mandatory.

AchimKraus DFU shouldn’t be any different from the nRF9160. It’s possible that the partition management side is not configured correctly.

You may need these guys set to make sure you’re not using external NOR flash:

# Do not use external flash for secondary
CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=n
CONFIG_PM_PARTITION_REGION_LITTLEFS_EXTERNAL=y
CONFIG_PM_PARTITION_SIZE_LITTLEFS=0x400000
CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=y

For me, zephyr or NCS seems to be fragile for switching static and dynamic pm-partitions. I prefer to use the static pm defined ny Nordic for the Thingy:91. That works for nRF9160 (thingy:91, dk, feather, mikroe) and nRF9161 (so far only for the dk).
I will try your configs, but “CONFIG_PM_PARTITION_SIZE_LITTLEFS” smeels for me to inhibit switching the pm-partitions.

AchimKraus I will try your configs, but “CONFIG_PM_PARTITION_SIZE_LITTLEFS” smeels for me to inhibit switching the pm-partitions.

Yup that’s fine. I put them all in there. That’s actually the settings for the nRF9160 Feather not the new board.

Glad you got it going!

Okkk!

Sorry for the lack of updates. I’ve been waiting for boards plus orders have been keeping Circuit Dojo HQ busy.

I digress. I mentioned this guy before but the first rev had some issues. A batch of the second version is built and ready to go.

It works with all Circuit Dojo Feather boards. (nRF91xx, nRF52833 (unreleased), etc) and supports use of the Raspberry Pi Debug Probe and 10-pin Segger JLink interface. I even went the extra step to bring out the reset pin for the 10-pin

Here’s the bottom:

I imagine this would be good for mass programming and also de-borking boards if you do something silly.

The design will be open sourced at the launch of the nRF91×1 Feather. I’ll have more on that shortly. For those folks who are looking for early samples I should have some this week as long as assembly & testing works out OK.

AchimKraus Awesome. Stay tuned on that front.

Lots going on here! I’m working on updating my test fixtures as an all-in-one. The first step is to transition the 1-up fixture and then the 9 up fixture.

I’m also just about ready to send boards over for RF testing. I will also have more boards for more beta/field testing. So for those who reached out to me, I haven’t forgotten about you.

More very soon.

Things are coming together with the all-in-one 1-up tester.

It looks like what I designed which is a plus . It will do all testing that I was previously doing across 3 test stations.

I also have some other news regarding the new board. Since the nRF9151 is fresh off the production line I decided to modify the nRF9161 Design to accommodate the new SiP.

It has the same features and functionality of the original design plus some room to grow as Nordic continues to develop on the platform. A few should be going out for FCC/CE next week if all goes well. The rest will be up for grabs once the tester is 100%.

Is there an update on the pyocd issue?

Just to mention: the nRF9161 prototype does a pretty well job on my side. Works since August without issues.

The pin VUSB is power input from USB? So it’s possible to power the device via that pin, if no USB is connected?

zpm1066 btw - I’ve been field testing nRF9131-EK for DECT NR+ and LTE-M/NB-IoT with GNSS. A very neat board, slightly longer than a Sparkfun Thing+ board, with nPM1300, nPM600, 256Mb external flash memory, and a Segger J-link OB. There are a few more enhancements coming down the line to make it even better.

I believe the 9131 does require more certification testing in order to legal deploy devices that use it. Versus the 9160, 9161 and 9151.

AchimKraus Is there an update on the pyocd issue?

I have not made progress. I’ve been focusing elsewhere. I have been playing with using probe-rs instead as it has been added as a target recently for Zephyr. I ported the pyocd code that updates the modem firmware also to use probe-rs (and using it in production). So I’m leaning to use that.

Just to mention: the nRF9161 prototype does a pretty well job on my side. Works since August without issues.
That’s amazing to hear. Thank you for testing it @AchimKraus !

AchimKraus The pin VUSB is power input from USB? So it’s possible to power the device via that pin, if no USB is connected?

VUSB is connected direct to the headers so you could power the device through the pin:

I have not tested if it plays well with USB. (it may work just fine) I typically recommend using VBAT pin for external power and turning the charger off. It depends on your application though.