Attempting to merge base sdk ble_app_blinky with mesh sdk sensor/server example.

[ccasebeer]

I am trying to merge the following projects:

SDK versions: 17.0.2 and 5.0

I have taken the contents of the mesh example sensor/server and merged it into the ble_blinky_example.

I am running into timer related merge issues.

I have successfully compiled but am confused on how to merge the following files.

From the ble_blinky_example I have the following timer related files and defines:

APP_TIMER_V2

APP_TIMER_V2_RTC1_ENABLED

/components/libraries/timer/app_timer2.c

from the mesh example I have the timer related files

/components/mesh/external/app_timer/app_timer_mesh.c">

./components/mesh/external/app_timer/app_timer_workaround.c">

Long story short, I was able to compile the two projects together with all source, but only by excluding the mesh related timer functions files, app_timer_mesh and app_timer_workaround. If I do this the base ble_blinky_app functions as normal and I can connect to it.

However, if I bring in the initialize() function from the mesh example, I have missing functions inside app_timer_mesh.c and app_timer_workaround.c.

I get multiple definitions such as this if I included everything:

  Linking ble_app_blinky_pca10056_s140.elf
    Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer_mesh.o: in function `app_timer_init':
    multiple definition of `app_timer_init'; Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer2.o:S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\libraries\timer/app_timer2.c:525: first defined here
    Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer_mesh.o: in function `app_timer_create':
    multiple definition of `app_timer_create'; Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer2.o:S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\libraries\timer/app_timer2.c:561: first defined here
    Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer_mesh.o: in function `app_timer_start':
    multiple definition of `app_timer_start'; Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer2.o:S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\libraries\timer/app_timer2.c:573: first defined here
    Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer_mesh.o: in function `app_timer_stop':
    multiple definition of `app_timer_stop'; Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer2.o:S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\libraries\timer/app_timer2.c:598: first defined here
    Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer_mesh.o: in function `app_timer_stop_all':
    multiple definition of `app_timer_stop_all'; Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer2.o:S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\libraries\timer/app_timer2.c:606: first defined here
    Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer_mesh.o: in function `rtc1_counter_get':
    multiple definition of `app_timer_cnt_get'; Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer2.o:S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\libraries\timer/app_timer2.c:626: first defined here
    Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer_mesh.o: in function `ticks_diff_get':
    multiple definition of `app_timer_cnt_diff_compute'; Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer2.o:S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\libraries\timer/app_timer2.c:621: first defined here
    Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer_mesh.o: in function `app_timer_pause':
    multiple definition of `app_timer_pause'; Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer2.o:S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\libraries\timer/app_timer2.c:631: first defined here
    Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer_mesh.o: in function `app_timer_resume':
    multiple definition of `app_timer_resume'; Output/Release/Obj/ble_app_blinky_pca10056_s140/app_timer2.o:S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\libraries\timer/app_timer2.c:636: first defined here
    Output/Release/Obj/ble_app_blinky_pca10056_s140/simple_hal.o: in function `button_event_handler':
    undefined reference to `timer_now'
    S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\mesh\examples\common\src/simple_hal.c:88: undefined reference to `timer_now'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/transport.o: in function `sar_ctx_tx_complete':
    undefined reference to `timer_now'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/transport.o: in function `tx_retry_timer_reset':
    undefined reference to `timer_now'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/transport.o: in function `rx_incomplete_timer_reset':
    undefined reference to `timer_now'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/transport.o:S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\mesh\mesh\core\src/transport.c:519: more undefined references to `timer_now' follow
    Output/Release/Obj/ble_app_blinky_pca10056_s140/timer_scheduler.o: in function `setup_timeout':
    undefined reference to `timer_start'
    S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\mesh\mesh\core\src/timer_scheduler.c:171: undefined reference to `timer_stop'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/timer_scheduler.o: in function `flag_event_cb':
    undefined reference to `timer_now'
    S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\mesh\mesh\core\src/timer_scheduler.c:178: undefined reference to `timer_now'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/timer_scheduler.o: in function `fire_timers':
    undefined reference to `timer_now'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/timer_scheduler.o: in function `timer_sch_init':
    undefined reference to `timer_init'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/timer_scheduler.o: in function `timer_sch_schedule':
    undefined reference to `timer_now'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/timer_scheduler.o: in function `timer_sch_abort':
    undefined reference to `timer_now'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/timer_scheduler.o: in function `timer_sch_reschedule':
    undefined reference to `timer_now'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/timeslot_timer.o: in function `ts_timer_on_ts_begin':
    undefined reference to `timer_now'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/heartbeat.o: in function `heartbeat_subscription_set':
    undefined reference to `timer_now'
    Output/Release/Obj/ble_app_blinky_pca10056_s140/net_beacon.o:S:\Desktop\remote_swedar\nRF5_SDK_17.0.2_d674dde\components\mesh\mesh\core\src/net_beacon.c:278: more undefined references to `timer_now' follow
Build failed

I can eleaborate, but in general, does anyone have any overall suggestions on merging the timing from ble_app_blinky with the timing from the mesh sensor examples?

Kind Regards.

[Karl Ylvisaker]

Hello,

but only by excluding the mesh related timer functions files, app_timer_mesh and app_timer_workaround. If I do this the base ble_blinky_app functions as normal and I can connect to it.

However, if I bring in the initialize() function from the mesh example, I have missing functions inside app_timer_mesh.c and app_timer_workaround.c.

This is because the app_timer used for the mesh is a slight modification of the app_timer existing in the SDK, which leads to your multiple definitions. However, since the ble_blinky example just uses the app_timer to monitor the button presses, you could rather change this to use the modified version of the app_timer from the mesh sdk, rather than trying to having each trying to use their own.

What functionality are you trying to achieve with the merging of these two examples?
Please know that it is not straight forward to merge BLE functionality into an existing Mesh example, since the mesh will use the radio 100% of the time, leaving no time for the BLE part.

From the functionality description you've provided above, it sounds like it might be helpful for you to take a look at the light switch example from the mesh SDK. This basically implements the ble_blinky functionality in a mesh implementation.

Best regards,
Karl

[ccasebeer]

Interesting.

This is surprising!

Our application is using BLE to probe/query/interact with a nrf52840 device but we also want to include that device inside a mesh network which is sharing sensor data (very small amounts) across multiple nodes.

This suggests that enabling mesh and well as standard BLE is not advisable, or that the project would need to be completely moved to mesh protocols? Is there any way to back off the mesh use of the radio to allow more time for standard BLE?

Appreciated!

[Karl Ylvisaker]

ccasebeer said:

Our application is using BLE to probe/query/interact with a nrf52840 device but we also want to include that device inside a mesh network which is sharing sensor data (very small amounts) across multiple nodes.

 Thank you for elaborating, this helps me understand your application use-case and issues.

ccasebeer said:

This suggests that enabling mesh and well as standard BLE is not advisable, or that the project would need to be completely moved to mesh protocols? Is there any way to back off the mesh use of the radio to allow more time for standard BLE?

Sorry, I see now that my previous comment perhaps makes it seem like this is not possible - this is not the case - I was just trying to emphasize that merging BLE functionality into an existing mesh example is not necessarily straight forward, but it is possible. It is done as you mention, by using radio timeslots, so that the BLE communications can happen every so often in between the mesh radio usage. This works, since the BLE protocol is made to minimize the time the RADIO is in use.
If you want to start looking at this, I recommend that you start by looking into the coexistance examples from the mesh SDK. These two examples demonstrate how BLE can be slotted into a mesh node.
For the functionality you describe it sounds like you should take a look at the UART coexistence example.
Using this example as a starting point, you can begin to implement both the mesh and BLE features you were seeking to achieve by merging ble_app_blinky into a mesh example.

Please do not hesitate to ask if any part of my answer should be unclear!

Best regards,
Karl

[ccasebeer]

I suppose I'm just trying to wrap my mind around if this is even a good idea, whether I should proceed with the merge of BLE and mesh/modify a coexistence example or not.

The BLE usage is basically for setup and query at infrequent interval....perhaps once a week or month. However, the mesh would be turned on and left on. Beaconing maybe once every 10 minutes or 60 minutes or possibly even less. Data isn't 100% locked in right now, but 1-5floats seems appropriate on the mesh.

Are there other stats on the BLE ormesh functionality which could help me gauge the ability of BLE to coexist with Mesh.

My gut says to keep going with the merge and/or the coexistence and see what falls out.

Another option that came to mind is having two firmwares. A BLE firmware and a mesh firmware and switch/boot/install between the two based on what is needed (setup vs running), or leverage two 52840's inside the device....one doing strictly mesh and the other doing strictly BLE.

Appreciate the guidance.

[ccasebeer]

I decided to look at the coexistance example as indicated. However, the project files are for a different board (not the 10056)

So I decided to start with the ble_uart app project for the 10056 and add in the mesh similarly to how the coexistance project does it.

I get right back to where I was with attempting to merge the mesh into the ble_blinky app.

If I sub app_timer2.c in the base sdk

for

app_timer_mesh.c and app_timer_workaround.c in the mesh sdk

the ble portion of the app no longer works. By no longer works, I  no longer am able to see the board advertising inside any of the nrF IOS utility apps.

If I sub back in app_timer2.c along with the two preprocessor defines:

APP_TIMER_V2

APP_TIMER_V2_RTC1_ENABLED

I am able to run the ble_uart demo in full.

I have compiled in all mesh sdk source (except app_timer_mesh and app_timer_workaround) needed for coexistance, I just don't call any of it in main in both instances.

Much appreciated.

[Karl Ylvisaker]

Hello again,

Thank you for your patience with this - the national easter holiday has just passed here in Norway.

ccasebeer said:

Are there other stats on the BLE ormesh functionality which could help me gauge the ability of BLE to coexist with Mesh.

My gut says to keep going with the merge and/or the coexistence and see what falls out.

It is definitely an option to have BLE coexist with mesh - as I said, it only requires a little bit of time from the mesh protocol, which wont affect its performance. For example, if mesh has the radio 98% of the time, and BLE 2% - or even less, as you suggest in your previous comment.
This is no problem at all. However, it is not straight forward to merge a BLE example into a mesh example, or vica versa. This is the point I tried to emphesize in my last comment, my apologies if I were unable to make this clear.

In short; coexistence of BLE and Mesh is absolutely possible and a good idea. However, it is hard to achieve this by starting out from either a strictly BLE or mesh example, merging them, and succeeding. Rather, you should start out from the existing Coexisting example.

I am really sorry for any confusion I might have caused here, from being inexplicit.

ccasebeer said:

I decided to look at the coexistance example as indicated. However, the project files are for a different board (not the 10056)

Luckily, it is easy to change the example to work with the nRF52840 DK.
The nRF52840 is the superset of the nRF52 family, so it has all the functionality that the subsets might have. This is part of what makes it the best development option for the nRF52 series SoC's. You will primarily need to change the SoftDevice, and adjust the section placement macros. Please see this answer by my colleague Simon.
You will also have to add the SES files for the pca10056 to the coexistence example, since these are not provided with the Mesh SDK.

Best regards,
Karl

[ccasebeer]

I have bought a PCA10040.

I have attempted to run the stock ble_app_uart_coexist.

I have not made any changes to the source. I compile and debug.

I run into a couple issues:

After connecting to the NORDIC_UART device, after awhile....I disconnect and the advertising stops. I can't find the device anymore.

I am unable to send strings to the NORDIC_UART using the nRF Toolbox app. If I compile the ble_app_uart itself and use the exact same procedure it works great.

I have yet to see the mesh sensor client part of the coexistence advertising on any of the IOS nrF apps. I can usually see the mesh examples advertising to be provisioned.

I have checked the SDK's for diff's with stock. I can't find any.

[Karl Ylvisaker]

Hello,

ccasebeer said:

I have not made any changes to the source. I compile and debug.

 Thank you for clarifying this.

ccasebeer said:

After connecting to the NORDIC_UART device, after awhile....I disconnect and the advertising stops. I can't find the device anymore.

That sounds very strange. Does the device reset when this happens?
Are you familiar with the nRF Sniffer tool? It is a very powerful tool when developing with BLE.
It would be very helpful to see a trace of the on-air BLE traffic when this occurs.
Make sure to select the device in the device drop-down menu, to see packets to and from that particular device.

ccasebeer said:

I am unable to send strings to the NORDIC_UART using the nRF Toolbox app. If I compile the ble_app_uart itself and use the exact same procedure it works great.

Do you mean that you are unable to send the string after the sudden disconnect, or do you mean that you never get to send a string to the device?

ccasebeer said:

I have yet to see the mesh sensor client part of the coexistence advertising on any of the IOS nrF apps. I can usually see the mesh examples advertising to be provisioned.

Are you using the nRF Mesh application, or the nRF Connect for iOS application?

Looking forward to resolving this issue together!

Best regards,
Karl

[ccasebeer]

Karl Ylvisaker said:

Do you mean that you are unable to send the string after the sudden disconnect, or do you mean that you never get to send a string to the device?

I am never able to send a string. After awhile of being in the UART IOS app as part of the nRF Toolbox for IOS and attempting to send the string, the app will eventually disconnect. So I am able to connect and attempt to send strings but they never show up in associated putty terminal attached to the nrf52 DK. When I compile and run the plain ble_app_uart and use identical procedures, I can use the nRF Tooblox uart app to send strings to the device and see them in the attached Putty terminal.

Karl Ylvisaker said:

That sounds very strange. Does the device reset when this happens?
Are you familiar with the nRF Sniffer tool? It is a very powerful tool when developing with BLE.
It would be very helpful to see a trace of the on-air BLE traffic when this occurs.
Make sure to select the device in the device drop-down menu, to see packets to and from that particular device.

Device reset does not appear to happen, as I am still connected to the debug session at this point and it is still running. I can absolutely try use the nRF Sniffer Tool around this error.

Karl Ylvisaker said:

Are you using the nRF Mesh application, or the nRF Connect for iOS application?

I have looked for the device in both apps. I don't see it in either.

It was recommended I also look at the ble_app_proximity_coexist, which I can do.

I haven't taken a trace with the nRF Sniffer. It'll take a bit of time to setup. I can do that though.

[Karl Ylvisaker]

Hello,

Thank you for your patience with this.
I just spoke with Gene and Scott, and they forwarded me your email exchange. One thing is however unclear to me, are you still pursuing the mesh functionality for your application, or have you now opted to go for the BLE Long range relay topology instead?
The last message in the exchange I saw had Scott detailing the power consumption of BLE relaying vs. Mesh topology, for reference.

ccasebeer said:

I am never able to send a string. After awhile of being in the UART IOS app as part of the nRF Toolbox for IOS and attempting to send the string, the app will eventually disconnect. So I am able to connect and attempt to send strings but they never show up in associated putty terminal attached to the nrf52 DK.

It would be great if you could capture a sniffer trace of this exchange - this will tell us exactly why the device disconnects, and confirm to us whether the attempted write goes through or not.
We will then know more about where to look for the root cause of this behavior.

ccasebeer said:

When I compile and run the plain ble_app_uart and use identical procedures, I can use the nRF Tooblox uart app to send strings to the device and see them in the attached Putty terminal.

Thank you for clarifying this, this is very helpful to have confirmed! 

ccasebeer said:

I have looked for the device in both apps. I don't see it in either.

For now, we can stick to the nRF Toolbox (or switch to nRF Connect application for smartphone, as this has more features and nRF Toolbox is deprecated) while we debug the BLE Nordic UART issue. Are you able to communicate with the mesh side of the application?
I.e does the Mesh light switch example functionality work as expected in the UART coexistence example?

ccasebeer said:

I haven't taken a trace with the nRF Sniffer. It'll take a bit of time to setup. I can do that though.

The sniffer may look daunting to familiarize with, but it is truly a powerful tool to wield when developing BLE application. It also takes a lot shorter to get up and running than what one might expect when first looking at it, luckily! :) 
It would be great to see a sniffer of the exchange you mentioned earlier, where you are able to connect and attempt to write something to the NUS service, before the sudden disconnect.

Looking forward to resolve this issue together!

Best regards,
Karl