• State Verified Answer
  • Replies 4 replies
  • Subscribers 85 subscribers
  • Views 2124 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 227128
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problem in evaluating Light switch example in Mesh SDK

HarshV

Hi,

I am evaluating nrf52 using  the light switch example for one of our future products. I have used Nordic nrf51/52 for BLE applications in several products. This is my first time using it for a mesh application. Here is the problem I am facing 

Environment:

Soft device :  s132_nrf52_6.1.0

Mesh SDK Version : 3.0.0

SDK Version: 15.3.0

IDE: SES (Used for building , downloading & debugging)

Provisioning method: Android App

So, I have three nrf52 devkits programmed with server, client & provisioner examples provided in the mesh SDK. All the executions start with all LED's blinking pattern (I am alive pattern?). Now, as mentioned in the readme file I can see `nRF5x Mesh Switch` & `nRF5x Mesh Light` on the Android app(nRF Mesh). If I click the `nRF5x Mesh Switch` it starts the provisioning. The app shows the processing bar with stages connecting --> Discovering services --> Initializing and then it's stuck. In this stuck state all the LED's are solid on. Also, the device can't be seen on the App anymore. The behavior is consistent with the server example as well.

Debugging:

After this, I attempted to debug to see whats going wrong and this is what I found.

<t:          0>, main.c,  321, ----- BLE Mesh Light Switch Client Demo -----
<t:      18686>, main.c,  288, Initializing and adding models
<t:      23438>, main.c,  361, Device UUID : 0059CCAA00000000920C81A3F4DF19A1
<t:     276714>, app_error_weak.c,  108, Mesh assert at 0x0002ACEA (:0)

I am getting a asset on "0x0002ACEA (:0)". When I used addr2line, the assert happens here:

harsh@harsh-B250M-DS3H:/media/harsh/ESD-USB$ addr2line -e light_switch_client_nrf52832_xxAA_s132_6.1.0.elf 0x0002ACEA
C:\Users\HRuchandani\Documents\mesh-sdk-3.0.0\examples\light_switch\client/C:\Users\HRuchandani\Documents\mesh-sdk-3.0.0\mesh\core\src/timer_scheduler.c:214 (discriminator 1)

Could you please assist with What's actually wrong here? as I have used dev kits and not even the custom HW yet. Please let me know if I missed a step or something.

Thanks. 

Parents
  • 0

    Hi,

    Are you using the unmodified example?

    Please note that the nRF5 SDK for Mesh v3.0.0 (and v3.1.0) are tested together with and compatible with nRF5 SDK v15.2.0. If you use nRF5 SDK v15.3.0 together with the nRF5 SDK for Mesh then you might see issues.

    The particular assert indicates that there is something wrong with the Interrupt priority levels.

    Regards,
    Terje

  • 0 in reply to tesc

    Hi Terje, 

    Yes, I am using the unmodified example. So are you suggesting that I go with SDK version 15.2.0. I am open to change the SDK at this point in the project but only if I'm not missing any functionality that is necessary.

    Here is what I actually want to achieve.

    * Dynamic (out of range provisioning of the mesh).

    * Combining beaconing concept with dynamic provisioning 

    * Low power node (may be)

    If this is all possible using the 15.2.0 and it is still supported by Nordic, I can switch. Please advice.

    Thanks,

    -Harsh

  • +1 in reply to HarshV

    Hi,

    I recommend that you use the latest version of nRF5 SDK for Mesh, which is currently v3.1.0.

    I see that in the documentation under "Getting started" -> "Installing the toolchain" we list nRF5 SDK v15.2.0 as "recommended minimum version", but I would still recommend to stick to 15.2.0. The sections "Downloading nRF52 SDK" on the same page has some information on where to put it.

    Regarding the example you should use only one provisioner, i.e. not both phone app and provisioner example. Using multiple provisioners is allowed by the Blutooth mesh specification, but how to share the provisioning database is implementation specific and we do not have any examples doing that. What we do have, is the remote provisioning example, which gives extended range to the provisioner by leveraging the mesh network for reaching the provisionee.

    Can you check with nRF5 SDK for Mesh v3.1.0 and nRF5 SDK v15.2.0, if you still see the same issue?

    Regards,
    Terje

Reply
  • +1 in reply to HarshV

    Hi,

    I recommend that you use the latest version of nRF5 SDK for Mesh, which is currently v3.1.0.

    I see that in the documentation under "Getting started" -> "Installing the toolchain" we list nRF5 SDK v15.2.0 as "recommended minimum version", but I would still recommend to stick to 15.2.0. The sections "Downloading nRF52 SDK" on the same page has some information on where to put it.

    Regarding the example you should use only one provisioner, i.e. not both phone app and provisioner example. Using multiple provisioners is allowed by the Blutooth mesh specification, but how to share the provisioning database is implementation specific and we do not have any examples doing that. What we do have, is the remote provisioning example, which gives extended range to the provisioner by leveraging the mesh network for reaching the provisionee.

    Can you check with nRF5 SDK for Mesh v3.1.0 and nRF5 SDK v15.2.0, if you still see the same issue?

    Regards,
    Terje

Children
Related
Terms of service