This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

mesh integration on existing firmware -- Program dwells on unknown function

Hi,

I just recently began implementing the mesh stack into an existing application, using mesh v3.2 and nrf sdk 15.2. 

Integration works well by using the integration guide provided in the infocenter, but the mesh doesn't start after initializiation.

in detail I basically tried implementing the mesh_main.c file from the sdk_coexist proximity example, initialization seems to work alright, my services are still visible on LightBlue but as soo as I start the mesh stack my programs will suspend on an unknown function 0x978. This doesn't happen in the SoftDevice but rather at the end of the nrf_mesh_enable function. Debugging doesn't give me an error either, the program basically just stops.

Any hints on what is going on here? I copied most of the configuration from the proximity coexist example as flash_placement specs and configurations from the app_config file, only some settings have to stay the same as before. 

Im using a nrf52840 and SD140 6.1.0

Would appreciate any kind of help!

Parents
  • Hi Juliusc, 

    It's important to be able to debug the application and see where the code crashed. You can use either breakpoint and step in the code or use logging to print out debug info. 

    Please check at exact which line the code stopped working. 

     I would suggest to use the proximity coexisting example as the base and integrate your application into the example. 

  • Thank you for the quick reply, let me put it like this, after the ble/mesh inits/starts my application goes into its main loop, makes a few cycles and then crashes. I can't really pinpoint the moment where it crashes its not at runtime so maybe a bluetooth event?

    I thought about that too but right now that'd be a lot of code tweaking since my application is quite large and customised

  • Please enable logging and try to debug. Do you see any assert ? hardfault ? The call stack should give you some hint of what caused the assertion. 

  • I did try so, the call stack is empty as soon as the application hangs on ldd r3 address 0x00000978

    From my understanding, this means that anything pauses the bluetooth activity and therefore crashes the program.

    Its what happens when you press pause in debug mode on a bluetooth application. I can't really pinpoint where it happens though

  • If you put a breakpoint when the softdevice is active and continue after that it will fail. The reason is that the softdevice uses some timer and when you break in a breakpoint the timers will not stop and they continue, this will confuse the softdevice and you won't be able to continue after you break in a breakpoint. 

    Please try printing out logging or use GPIO toggling to debug. 

    I would suggest to simplify down the code, turn off other functionality and try to get just the softdevice (BLE) and mesh running. It would be easier to spot what's wrong on a minimal firmware. 
    You can send us the minimal firmware that can reproduce the issue on a nRF52 DK so we can test and debug here. 

Reply
  • If you put a breakpoint when the softdevice is active and continue after that it will fail. The reason is that the softdevice uses some timer and when you break in a breakpoint the timers will not stop and they continue, this will confuse the softdevice and you won't be able to continue after you break in a breakpoint. 

    Please try printing out logging or use GPIO toggling to debug. 

    I would suggest to simplify down the code, turn off other functionality and try to get just the softdevice (BLE) and mesh running. It would be easier to spot what's wrong on a minimal firmware. 
    You can send us the minimal firmware that can reproduce the issue on a nRF52 DK so we can test and debug here. 

Children
  • Hey Hung, so Im playing around with this a lot but can't really get a stable version.

    I tried disabling the timer in the sdk_config since that's what's up in the proximity example as well and it does seem to work but my static provisioner still can't find the node. There must be something with the times lots somehow, I disabled every other peripheral and function and only init able and mesh. Im 100% certain its not in my code, since I copy and pasted the prox examples main files into my solution and excluded my own application from the built and still can't provision it, it must be somewhere else but I literally copied all of the settings for the linker/flash/sdk_config/preprocessors so Im really puzzled here. 

  • Please check if it still run or it crashed at some point. 

    Did you see it advertise as a normal BLE device (not mesh)?

    I assume you use the static provisioner, not the phone to provision the node , correct ?

    If the node already provisioned it won't show up in the list of provisionees.  

    If the firmware can run on a DK, you can send us the (minimal) firmware so we can test here. 

  • it doesn't crash, I can use normal blue yes, pairing works fine, the static provides doesn't find the mesh device though. Also I do know about the fact that it needs to be unprovisioned but it also isn't. 

    anything else there is left to do? quite hard to send minimal firmware when so many things are depending on each other.

    thanks for all your suggestions though, this aint an easy problem, mesh hasn't been my best friend to date ;)

  • btw one thing I notice on my way is that if I disable all the timers in the sdk_config, the dwelling doesn't happen anymore and ble works but not mesh. Do you have any input on that? 

  • Hi Julius, 
    I think the best way now is to start from scratch. I don't say that you need to re-implement you application from scratch but to use a BLE example (the one that you based your application on) and then add mesh in to the example. 
    This way if anything go wrong the same way as in your application it would be much easier to debug. 

    Regarding the timer, please double check and make sure app_timer_mesh.c is used, not app_timer.c 

Related