BLE-mesh hundreds nodes test bench by means of nRF52840-Dongle, starting from nRF52840DK

[DavideDN]

Hi,

We have the opportunity to study and test a BLE-mesh network with a few hundred nodes.

One idea to limit the costs and avoid rebuilding wheels is to implement it using your nRF52840-Dongle devices, their are cheap enough to fit our budget.

We already have a few nRF5340DK's and nRF52840DK's along with nRF52840-Dongle samples.

We already successfully built small mesh networks using your mesh-light and mesh-switch example projects, everything is working as expected.

Using the DK boards everything went smooth: we got the examples, we modified little details to test and start learning the nRF Connect ecosystem and the VS Code extensions... All worked as intended and expected, we are pleased and satisfied.

Now we want to start building the real test bench for our project: we need to flash some nRF52840-Dongle with the project we already tested on the nRF52840DK.

Of course we need to deal with a little different memory shape to account for the MBR and the bootloader.

We browsed the internet and some post in the devzone, we tried simple steps, but we were not able to flash a working image using the "programmer" found inside the "nRF Connect for Desktop" suite.

We understand that without the correct memory layout we cannot achieve anything, may be we are too much of newbies to understand the right steps.

We found the following references, but they appear somewhat outdated and/or not dealing with the BLE-mesh examples and/or the new toolchain/workflow (I mean the nRF Connect SDK).

 nRF52840 Dongle Programming Tutorial 

 Flashing nRF52840 dongle from Visual Studio Code using nrfjprog as in the Makefile 

 nRF Connect VS Code flash nrf52840 Dongle 

We wish to understand what is the "best practice" and/or official approach to transfer a working "nRF Connect SDK" Ble-mesh example from a nRF52840DK to a file that can be flashed into a nRF52840-Dongle using the "nRF Connect Programmer" using the USB connection only (no J-link approach).

Is there a reference document? May be we missed some academy course on the topic? If not, can you kindly provide some explanation/documentation/suggestion related to the current nRF Connect SDK and avoiding NRF5 SDK?

Inside the first post I just linked we read:

"The nRF52840 Dongle is a superb companion for several nRF Connect for Desktop apps and is a good device for doing large scale mesh test setups and similar, with its low cost and small size. It can also be used for development, and easily programmed over USB DFU from nRF Connect Programmer. "

So, please help us in making that sentence true: we are building a hundred node BLE-mesh prototype.

Our idea is to develop our mesh application using the DK boards, then as soon as new prototype fw will be verified and debugged inside the DK, we wish to prepare a different build to obtain the same application flashable into the "dongles" using nRFConnect Programmer and/or DFU mechanisms.

Thank you in advance and kind regards.

  Davide De Nardis

[tesc]

Hi,

I have looked into porting nRF Connect SDK mesh samples to the nRF52840 Dongle today. In theory porting any sample to the Dongle should be pretty straight-forward, but in practice I have not (yet) succeeded in porting a working nRF Connect SDK mesh sample.

Currently I am at a stage where I have programmed the mesh application onto the Dongle, after the following steps:

1. Make a build configuration for the nrf52840dongle_nrf52840 board.
2. Build the project.
3. Find the merged.hex in the zephyr subfolder of the build folder.
4a. Using that hex file, follow the instructions under "Program application using nRF Connect Programmer" in the nRF52840 Dongle Programming Tutorial.
4b. Alternatively, instead of 4a: Follow the slightly longer path of "Programming an example using nrfutil". With the latest versions of nrfutil (version 7 and newer) you must first do "nrfutil install nrf5sdk-tools" for installing the legacy commands. Follow the description for creating an upgrade DFU package containing only an application, and use 0x00 for --sd-req.

However: Even though everything seems to have been done by the book, with an application programmed to the dongle, and the bootloader seemingly still working fine, the mesh application seems to be not working. I wish I could be more descriptive than "not working," but what I can say for sure is there are no LEDs blinking, and the nRF Mesh app is unable to scan the device. Debugging this is, of course, a bit challenging, thanks to the fact we are on a dongle and not on a DK.

Maybe it is as simple as the application requiring buttons, leds, etc. not present on the dongle. Maybe it is more subtle. I will continue looking into this tomorrow, for then to (hopefully) provide a full description of what is needed, for getting an nRF Connect SDK mesh sample up and running on the nRF52840 Dongle.

Regards,
Terje

[alebldn]

Hi Tesc, thanks for your comment.
I'm Alessandro and I'm working on this project with Davide. I'm writing this comment to give you more insights about the problem we're facing.

First, we have made the decision not to use nrf5 sdk or nrfutil (so far, at least) because of the status of the project: considering that nRF5 SDK is in maintenance mode and nrfutil are deprecated, we didn't really want to start working on these tools for our new project. So far, and until it isn't strictly necessary, we're planning to use nRF Connect SDK.
About the project itself, before posting in this forum, we already tried the steps you suggested on two different sample projects. The first one, blinky, works without any problem whatsoever: modifying the source code to any custom code we made resulted in a perfect execution. On the other hand, for mesh light, as you have experienced yourself, the procedure doesn't really work. Now, this was actually foreseeable since the board is not compatible with the project and, in the compatible board field in the build configuration it does not show up (though, we tried it both on the 5340dk and 52840dk and both worked as a charm).
The follow up question here is then: "what makes a project compatible with a board?".

To figure this out, we tried the following:
1. Comment the initialization of bt_mesh in the main and replacing it with a simple blinky example.
2. Comment the specific libraries for DKs (<bluetooth/mesh/dk_prov.h> <dk_buttons_and_leds.h>)
3. Considering the non availability of a debugger or a serial port, we also commented all printk (and k_msleep as well).
4. Changed sample.yaml to include the compatibility with the dongle.
5. Setting CONFIG_NCS_SAMPLES_DEFAULTS=n in the prj.conf file (also via Kconfig).
6. Changing the default values of CONFIG_USB_DEVICE_VID and CONFIG_USB_DEVICE_PID in prj.conf file as suggested at build time.

Unfortunately, while we got no errors in building these attempts, none of them produced a significant result. So far, considering that we didn't yet solder the dongle to a debugger, our only way to understand the depths of the chip was to use its leds. So we did: by replacing the bt_mesh main (and just the main) with a blinker that toggles the blue we noticed that the board actually resets after a little while. Here's a snippet:

int main(void)
{
	
	if (!gpio_is_ready_dt(&led)) {
		return 0;
	}
	
	if (gpio_pin_configure_dt(&led, GPIO_OUTPUT_ACTIVE) < 0) {
		return 0;
	}
	
	gpio_pin_toggle_dt(&led);
	/* commented bt_init stuff */ 
	for(int i = 0; i < 10; i++) {
		gpio_pin_toggle_dt(&led);
		k_msleep(SLEEP_TIME_MS);
	}

	return 0;
}

    
The code toggles the led 11 times so to have the led turned off at the end of the for loop. After that, the main returns. What happens is that the led blinks as requested then, after a while, it starts blinking again.
The only time I've seen this happening before was when we flashed this same example (mesh light) in the
5340dk with debug options enabled, producing a StackOverflow error resulting in the board resetting.
The thing is, though, that this very example works on the DK having the same amount of flash and the same amount of RAM. So, I figure, maybe it might be about a specific configuration of the stack size for the dongle?
I tried then to modify CONFIG_MAIN_STACK_SIZE (both lowering it and increasing it) in prj.conf with no result so far. If i find anything new, I'll post here.

Unfortunately, I'm fairly new in coding with this architecture. But again, thanks for your effort, it really is appreciated!

[tesc]

Hi,

alebldn said:

So far, and until it isn't strictly necessary, we're planning to use nRF Connect SDK.

Yes. This is the correct decision.

Now, the issue is, since the Dongle does not have an on-chip programmer, it comes equipped with a DFU bootloader. This DFU bootloader is the DFU bootloader from nRF5 SDK.

In nRF Connect SDK, the nrf52840dongle_nrf52840 board configuration is for building nRF Connect SDK applications that are compatible with the nRF5 SDK bootloader. For programming the Dongle you can then use either the nRF Connect for Desktop Programmer app, or you can use nrfutil (with the legacy commands for working with the nRF5 SDK DFU bootloader.)

alebldn said:

The follow up question here is then: "what makes a project compatible with a board?".

This is a good question. It involves what is connected to the GPIOs (such as buttons, LEDs, etc.), but it may also involve clock sources, voltage levels, etc. The latter (clock, voltage) should be handled by the board configuration, but number of buttons, LEDs etc. will of course affect compatibility.

alebldn said:

The thing is, though, that this very example works on the DK having the same amount of flash and the same amount of RAM. So, I figure, maybe it might be about a specific configuration of the stack size for the dongle?
I tried then to modify CONFIG_MAIN_STACK_SIZE (both lowering it and increasing it) in prj.conf with no result so far. If i find anything new, I'll post here.

If you get a stack overflow, then there must be a root cause for that; some code flow must be different when run on the Dongle, compared to when run on the DK. My current main suspicion is the logging. Without time to check, I suspect the mesh samples log to UART or RTT, which could fill buffers on the dongle (since no PC or other device is reading the logs). That would be a good place to look.

I have also asked our Bluetooth mesh team, internally, to see if we have any tips and tricks on how to port samples to the Dongle. Hopefully we do know (at least internally) what needs to be done, even if I have not found any solution in existing DevZone tickets (neither private nor public.)

If the team does not have any answers, the next step would be a debug session after connecting to the 10 pin TagConnect pads from a J-Link programmer (for instance from the debug out port of an nRF DK).

Regards,
Terje

[alebldn]

Hello again, I have a (small) update:

I'm still playing with the software for fun, trying to blindly find out what is wrong while we wait for an in-depth answer from the dev team and I found out that setting

CONFIG_NCS_SAMPLES_DEFAULTS=n

(while keeping bt_enable commented) allows the dongle not to be reset.

Unfortunately, even setting the log-related configs to no (or to minimal) or disabling the RTT and UART console doesn't make the sample work when bt_enable is not commented.

I'll keep working on this.

Best wishes,

Alessandro