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

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

  • Hi Terje,

    we wish to receive some update.

    Being able to use the nRF52840-Dongle is something we gave as "taken", also because the dongles could be thought as some project we are designing using the nRF52840 chip, as for some specific project of ours.

    We see the problem as something totally internal to Nordic SDK (libraries, documentation, whatever..). We did not planned (and we are not sure if we could afford to) to put efforts in discovering the root cause of these malfunctioning, after all is none of our code, we used the SDK examples.

    Then my question:

    Is Nordic planning to fix this? What are the estimate time for a solution or fix?

    On our side we need to understand if our 200-300 nodes BLE-Mesh can be built using Nordic dongles or a specific project/HW is needed. This can seriously affect our evaluations and effort planning.

    Thank yuo in advance.

    kind regards

     Davide

  • So, after days of research we found a solution thanks to user Elfving. I'm posting this for the sake of possible readers that might find themselves having the same problem we have faced. Here's the link: Solution.

    Still, it would be great to have a full document to guide us in making non-compatible boards compatible with different projects. This would also be beneficial for the dev team.

  • Hi,

    I can confirm we currently have no nRF Connect SDK based Bluetooth mesh samples for the nRF52840 Dongle.

    That being said, developing nRF Connect SDK based Bluetooth mesh applications should definitely be doable on the nRF52840 Dongle, at the same level as with any custom hardware with the nRF52840 SoC.

    What is special on the Dongle is mainly the preprogrammed bootloader. I see it has now been mentioned in this thread an issue with data stored by the mesh stack (data which needs removal through some extra steps), which definitely looks like a pitfall. This may be the full solution, or it may be part of the solution.

    Two additional pitfalls are voltage level and clock source, which differs from the DK. Those should already be handled by the board file, though.

    I have during my testing figured out that the mesh samples seem to (at least partially) work when a debugger is connected. This could be e.g. that clock is not successfully started. However after provisioning there seems to be some configuration errors on the node itself, where the app key gets corrupted. This is possibly related to flash memory usage conflicts with the nRF5 SDK based bootloader, but I have not yet investigated that path to conclusion.

    In general, issues with nRF Connect SDK Bluetooth mesh samples on the nRF52840 Dongle seems to be mostly linked to coexistence with the nRF5 based bootloader. There are two potential solutions to this. First solution, identify and fix the issues, still using the nRF5 SDK based bootloader. Second solution, use a programmer to program the Dongle with a fully nRF Connect SDK based solution.

    I do hope to have more information later this week, but it may delay until next week.

    Regards,
    Terje

Related