Provisioning error in Light Switch server (NRF52832)

[Dmitro Balo]

Hello! I am trying to run the "Light switch" example on a custom board.

My environment:
- nRF5 SDK v17.0.2
- nRF5 SDK for Mesh v5.0.0
- SoftDevice S132 v7.2.0
- NRF52832_xxAA (on custom board)
- Keil uVision 5.33.0 (Compiler v5)
- J-link debugger
- nRF Mesh App v3.1.6 for Android

I'm using Keil's built-in MDK. When trying to add a device to the network, nRF Mesh reports an error:

The example code remained unchanged, except for the fact that I commented out all calls related to the board (controlling the LEDs). After the error occurs, my log looks like this:

While debugging, I was able to figure out that the "m_device_provisioned" flag is set to "true" at this location:

However, after that, the GATT connection is closed, as evidenced by the call to the "a_link_close_notify" function, which informs subscribers about the NRF_MESH_PROV_LINK_CLOSE_REASON_ERROR error:

Call stack up to this function:

When compiling the project, I see that some of the declared sections do not have observers registered, but the project starts successfully:

I hope for your help!

[Dmitro Balo]

Thanks for the answer! I checked the original example, no changes - it still doesn't work. Also, I tested on several different phones and the result is the same. This time, I did not launch nRF Connect while NRF Mesh was running. After provisioning ends, my device receives BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION and then the "prov_provisionee_cb_link_closed" callback is called with the reason "NRF_MESH_PROV_LINK_CLOSE_REASON_ERROR". I'm not sure if this is how it's supposed to work, but the node doesn't advertise as "provisioned", it doesn't show any signs at all until it reboots. After the reboot, it again sends out advertising for an "unprovisioned" device.Can I send you a project so you can help me? 

[Hung Bui]

Hi Dmitro, 
Sure you can send us your project and your hex files. 

I also attached here my hex file for you to test. Do you have a DK to test ? 
Have you verified that the custom board can run any other BLE application ? 

6433.light_switch_server_nrf52832_xxAA_s132_7.2.0.hex

It's normal that the connection is dropped after provisioning because we need to reset the softdevice after that. But after provisioning it should advertise and re-connect to continue the configuration process. 

[Dmitro Balo]

Hi Hung,
I uploaded your hex to my board and it works great. I've tried other SDK examples and they behave the same - provisioning doesn't complete. After the device receives some data from the provisioner, it should reboot and then continue the provisioning process. Before these, it is necessary to save the received data such as the network key, unicast address and other data to the persistent storage (flash).
My example, after receiving the data, cannot reboot due to the fact that writing to the flash does not occur. After running the "process_action_queue" function in the "flash_manager" module, the memory write action is retrieved from the packet buffer, and the "m_action_state" remains in the "ACTION_STATE_WAIT_FOR_FLASH" state forever, but the problem is not with the memory write itself, because after the action is retrieved, the function call "flash_op_start" never happens, "bearer_handler_action_enqueue" is called. After calling "bearer_handler_action_enqueue", I noticed that TIMER0 (compare) interrupts are disabled, the main loop executes the sd_app_evt_wait function indefinitely, no hard fault occurs.

[Hung Bui]

Hi Dmitro, 
It's a little bit strange that when you flashed my example it worked fine. I assume the provisioning goes smoothly from provisioning until configuration completed ? 

It's the unchanged light switch server example from the SDK so if you compile your example it should result the same. 

Could you please compile and send us the hex file of the light switch server example in the SDK  ? so we can test here. Have you tried to test with a fresh SDK installation ?

[Hung Bui]

Hi Dmitro, 

I didn't notice that you were using KEIL. 

Could you please test using Segger Embedded Studio  ? (It's free to use with Nordic chip)

The problem is that the nRF5 Mesh SDK is not made for KEIL and we didn't have any test on that. 
From what you described I suspect that it's the issue with the flash section declaration (including the observer sections also missing). 

I would strongly suggest to switch to SES/gcc instead of KEIL.