Flashing A Wurth Proteus III with the NRF Mesh SDK

[john_developer]

So the goal of what I'm doing is I have a Wurth Proteus III and I want to run the NRF Mesh SDK provisioner on the Proteus III. I have been told that this is possible and through my research online have found documentation on how to do this. That being said I'm having plenty of issues even getting the provisioner application to build the solution before I even flash it. 

https://www.we-online.com/catalog/media/o172493v410%20ANR009_Proteus-III_Advanced_Developer_Guide.pdf

The link above is the documentation I found on how to do it (starting on page 26 is where the tutorial begins). The main issue I'm having is where it says to link the Proteous III hardware instead of the nordic evaluation board hardware. By adding the BOARD_PROTEUSI macro and removing the nordic macro. Where is this done in Segger? When I try to link the Proteus III and then build the solution I just get an "Error starting process = " Message. 

I know that this is an odd question because I'm using Wurth hardware but I figured I'd give it an ask since it's nordic's Mesh SDK I'm trying to run on it. 

Any help is appreciated,

Thanks

[tesc]

Hi,

The Wurth Proteus III is a module with an nRF52840 SoC inside, and so this should be no different from any other nRF52 based module or custom board with an nRF52 SoC on it.

The way different boards are handled in the nRF5 SDK (also inherited by nRF5 SDK for Mesh) is that under <nRF5 SDK root folder>/components/boards/ you will find header files for various boards. The file boards.h is a big switchboard, selecting what board file to include based on preprocessor defines. I see that the Wurth Proteus III guide follows this way of doing things, which is good.

In the nRF5 SDK for Mesh SES project, open the project options. (E.g. from the "Project" menu -> "Options...", the default keyboard shortcut is Alt + Return.) In the options, under Code -> Preprocessor, you have "Preprocessor Definitions". Things are a bit complicated in SES regarding this, as you can have differetn settings for Debug and Release builds, as well as you can have settings on a higher level than project level (solution level, spanning multiple projects.) Figuring out where a preprocessor define is defined can be a bit tricky, but the define you are looking for you must select "Common" in the dropdown and be on the "project" level:

Note that there are some differences between the nRF5 SDK, and the nRF5 SDK for Mesh, so following a guide for one does not necessarily translate directly to the other. While not exactly what you are doing, there is documentation as part of the nRF5 SDK for Mesh documentation, for integrating Mesh into nRF5 SDK examples. Anything that guide mentions as required or optional changes to the nRF5 SDK, may be things that the Wurth Proteus III guide expects to be different than what they are in the nRF5 SDK for Mesh. So if you experience issues down the road, that could be a first place to look for clues. And of course feel free to ask here if our documentation does not help.

Regards,
Terje

[john_developer]

Hi Terje,

Thanks so much for the response! I was able to flash the Proteus III with the provisioner mesh but it doesn't seem to be advertising? When I scan using the nRF Mesh application on my phone I don't get any signal out of the Proteus III. I tried to adjust the pinouts in the code for the Proteus but that doesn't seem to be working?

To just double check, to build a mesh network I want to deploy the provisioning application from the Mesh SDK onto my gateway module (my Proteus III), then I have a Proteus II that I am trying to deploy the the light_lightness_client mesh application onto. Is that the correct application set up to be able to successfully create a mesh network? 

Thanks so much for the help!

John

[tesc]

Hi,

To set up a Bluetooth mesh network, you need one or more nodes, and you need a provisioner. The provisioner can be either an nRF based device, or a smartphone. If you want the smartphone with nRF Mesh app to be part of the network, the easiest by far is to only use the nRF Mesh app for provisioner and not use a different device for provisioning.

I suggest a first step of porting the light switch server example to the Proteus III, as per the descriptions, and to test only with this one node first, using the nRF Mesh mobile app for provisioner. That way you minimize the number of devices and thus the number of things that might be wrong.

See the "Evaluating using the nRF Mesh mobile app" chapter of the Light switch example documentation.

If you have access to an nRF52 DK (or other nRF device DK supported by the nRF5 SDK for Mesh) then using the example directly on that one would quickly let you know what is supposed to happen, so that any errors in method could be ruled out.

Regards,
Terje

[john_developer]

Terje,

I was able to use an nRF52833 board with the light switch server example and provision it on my phone. So I know it is not a method issue or Mesh SDK issue. I believe it is a hardware issue in regards to porting the nRF Mesh SDK into the Proteus III. I know the pinouts for the Proteus III are different than the nrf52 pin outs. If I were to manipulate the ports and pints in the PCA10100 header file in the nRF52833 switch server example for the Proteus III would that make the application work on the Proteus?

Thanks so much for all your help,

John

[tesc]

Hi,

Getting the pinout right may be the full puzzle, or it may be part of it.

For instance it may be that the module uses a different LF clock source than the DK (available options depend on on-board components.) There is a SoftDevice setting in the sdk_config.h settings file for the nRF5 SDK modules, for SoftDevice clock configuration, named NRF_SDH_CLOCK_LF_SRC, where default setting is NRF_CLOCK_LF_SRC_XTAL, for using external crystal on the board. If the module does not have such a crystal, you need to select a different option. This means potentially other settings need to be changed as well. See e.g. nRF52 Softdevice Stuck without External Low Frequency Clock Source for more details.

Similarly, for other nRF5 SDK modules, there are other *_LF_SRC settings in sdk_config.h that may need a change if those modules are used in your project.

Regards,
Terje