Zigbee examples nrf52840 Dongle

[teeuu]

Hi,

I was just wondering if the nrf52840 Dongle is in some ways inferior to the other development boards in terms of its capabilities?

As I was going through the examples I noticed that the Dongle is not listed as a supported hardware platform here and is only present for the ncp.

And most entries for the memory requirements are also not given.

So is this just a lack of adding support for the dongle or is there an inherent reason why this will not work?

I have selected the nrf52840 Dongle because I assumed that the nrf52840 chip will be the same as with the DK, and more capable as some of the other nrf5xx DKs and because it is just so practical to use.

[mytzyiay]

On my Zigbee projects I have been using a couple dozen Dongles for prototyping / testing / power measurement and one DK for development.  The main differences I've encountered are:

1. Most of the Nordic samples use multiple DK buttons and LEDs, which work differently on the dongle.
2. Partition layout + programming is annoying on the Dongle if you flash it using the Open Bootloader.  Easier if you solder the two SWD pins, connect to a J-Link, and nuke the bootloader.  But this isn't very well documented AFAIK.
3. No external flash means that your code space is halved if you're using OTA A/B updates.  For my application this was fine, because we're just using the internal nRF52840 flash and our firmware comfortably fits in half the flash.
4. Dongle RF performance may or may not be so great.  Don't have enough data yet to know for sure.
5. Dongle is super easy to run off battery power (or a PPK2): cut SB2, solder SB1, connect 3V on VDD OUT.  No need to worry about current drain from other random chips because the design is dead simple.

All told the Dongle is a great little board for USD $10.

[teeuu]

Thanks mytzyiay for this extensive answer!

1. That's too bad, not sure why the Zigbee bulb or switch example would need those extra buttons and LEDs, but I get your point. But from my point of view, Nordic could improve on that.

2. I encountered some difficulties with flashing the device. Does the programming annoyance stem from poor tool support or is it just the layout you mention? I saw a lot of documentation using `nrfjprog` which I assume is also the one supported by VS Code and this apparently will not work with the Dongle. If that is the case, I would hope Nordic will do better in the future.

Yeah, I just got two of them because they are cheap, small and easy to use.

But I did not check out the documentation and tool support beforehand in detail. I would hope that Nordic improves on the documentation regarding the Dongle, provide more samples and simplifies the programming, because the Dongle is probably the first device someone gets to just try something and that should not add more frictions to getting started.

[mytzyiay]

teeuu said:

That's too bad, not sure why the Zigbee bulb or switch example would need those extra buttons and LEDs, but I get your point. But from my point of view, Nordic could improve on that.

Unfortunately these samples are missing a few things you'd need to build a real, productizable Zigbee device.  The biggest problem I found was that the default memory limits (even in the max configuration) are incorrect and they will cause the device to be unstable on all but the most trivial Zigbee networks.

It would indeed be useful if you could build these samples in some sort of an optional "product" configuration that shows the simplest possible production-worthy Zigbee device.

teeuu said:

I encountered some difficulties with flashing the device. Does the programming annoyance stem from poor tool support or is it just the layout you mention? I saw a lot of documentation using `nrfjprog` which I assume is also the one supported by VS Code and this apparently will not work with the Dongle.

If you want to program through the USB connector and not through the SWD pins:

1. You can't use nrfjprog.  From the command line you can do something like: nrfutil pkg generate --debug-mode --hw-version 52 --sd-req 0 --application zephyr/merged.hex dfu.zip; nrfutil dfu usb-serial -pkg dfu.zip -p "${DEV}" -b 115200 .  From the GUI you can use the Programmer app.
2. You might have to override the partition map so that the app doesn't scribble on the reserved bootloader area at 0xe0000 - 0xfffff.

If you want to program through the SWD pins, you should set CONFIG_BOARD_HAS_NRF5_BOOTLOADER=n so that the app overwrites the preinstalled bootloader and starts executing from address 0x0.  You might also need to run nrfjprog --recover; nrfjprog -e

From what I've seen, it's not easy to flash via SWD if the bootloader is being used, because the bootloader wants to update its internal data structures to match the app's checksum.