I am working on nRF52-DK using the light client example under Mesh 2.1.1
I am trying to start and stop the listening for provisioning packets as the idea is to switch to provisioner role and then switch back to provisionee role.
The code is by default setup that it starts sending out unprovisioned beacons and this works nicely. After 10s I execute a call for nrf_mesh_disable() followed by nrf_mesh_prov_listen_stop(&m_prov_ctx);
No matter what I try after that doesn't start the sending unprovisioned beacons again.
First I tried calling the start function from the example that starts the mesh and initializes the listener, but that didn't go through as the p_bearer was already set, so the ASSERT got triggered
the list_compare_add was failing as there was a p_bearer left after executing nrf_mesh_prov_listen_stop. Mesh error number returend was 95.
Then I tried calling nrf_mesh_enable() followed by nrf_mesh_prov_listen(&m_prov_ctx, m_params.p_device_uri, 0, PROV_BEARERS) that should start the listening
This would return with NRF_SUCCESS and the software would continue running until it was time to dispatch the advertisement packet about 2s later. At this stage it would break with the following call stack with error number 95. Which I haven't figured out yet where to find the meaning
There seems to be something wrong with the advertisement packet struct and it fails when trying to free a packet.
Am I missing some function calls that should be done before or after calling the start and stop functions for listening?
Any help would be appreciated
Could you explain me a little bit more on what you plan to create ? You want to make a provisioner who also is a provisionee ? I'm not sure what is that for.
Why do you want to call nrf_mesh_disable() when you just want to stop listening ? Can you just call nrf_mesh_prov_listen_stop() ?
When you see an assert with an address (0x2C7C2 in your case) , you can call addr2line.exe -e yourelffile.elf 0x2C7C2 to see where the assertion occurs.
Thanks for a quick reply.
The customer has some special algorithm they want to employ on the mesh that requires that some devices switch roles from time to time. I cannot disclose the algorithm due to NDA stuff but essentially I need a functionality where a device switches roles. Preferably done inside of nRF52 chip. Otherwise maybe it would make more sense to use the serial API and just use nRF52 as a modem, any suggestions on that?
I have tried with and without calling nrf_mesh_disable, either way I get the error when after nrf_mesh_prov_listen_stop() I call the nrf_mesh_prov_listen() and I also get an error if I try to reinitialize by calling the mesh_provisionee_prov_start() after stopping it.
I have found where the assert happens. After I call the nrf_mesh_prov_listen(), which returns NRF_SUCCESS, and the time comes to send out an advertisement packet. For some reason when it tries to fetch the next packet if fails to do a buffer free function. It seems like some flag does't get reset/set when the listen is started again
Thanks in advance
Could you let me know what exactly the error code was ? We don't see a reason why you couldn't switch role.
Could you send us a simplified version of what your customer planning to do so we can try here ?
We don't suggest to use nRF52 as a provisioner because of the limitation of the chip. It's easier to store and handle database on a PC/phone. But we would need to know more about the application to give you advice on how it should be done.
The error number returned was 95.
Essentially the gateway should be both a node and a provisioner. But due to the issues with role switching and limited space in the nRF52 we have decided to use the nRF52 as a modem and keep all the information in the host processor on the gateway. In this way we can easily change the role and reset the modem if things go really wrong.
I think it's the way to go. Could you take a screenshot where you find error 95 (0x5F ?) ? I don't think we have such error code.
As I am still new to development on nrf52 the assert message was indicating the place of the print statement not the error number. Duh
Attached is the screen shot of the code that rises the assert when processing the packet before it is sent
Thanks, look like a buffer issue, we will try to reproduce and report to R&D.