Hello, when trying to finish provisioning my nodes (3 total, per example program's instructions), my provisioner program keeps running into
NRF_MESH_EVT_PROV_LINK_CLOSED
and this is the rough flowchart:
Note the dash arrow connection line means I don't know what happened in between, but I can only guess some sort of time out took place...
What could be the problem??
Also, after reaching NRF_MESH_EVT_PROV_LINK_CLOSED, this is the part of program it went next:
__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Provisioning failed. Retrying...\n");
m_prov_state = PROV_STATE_WAIT;
How should I proceede next to make it goes to
NRF_MESH_EVT_PROV_COMPLETE
??
Follow up:
I've found the more detailed program flow but nevertheless don't have the knowledge sufficient enough to decode WHY it behaves the way it does, so this is how it goes:
main() -> nrf_mesh_process() -> transport_sar_process() -> status = trs_sar_rx_process()
then, right in the middle of executing
trs_sar_rx_process()
, most likely when executing
(void)trs_sar_drop_session(p_sar_ctx, NRF_MESH_SAR_CANCEL_REASON_NO_MEM);
, QDEC_IRQHandler
kicks in, and things go down hill from there, this is what happens:
EVENT_IRQHandler(void) -> handle_events() -> m_flag_event_callbacksi -> fire_timers(time_now )
-> p_evt->cb(time_now, p_evt->p_context) -> adv_evt_timeout(timestamp_t timestamp, void * p_context)
-> p_advertiser->queue_empty_cb(p_advertiser) (AKA close_link(prov_bearer_adv_t * p_pb_adv, nrf_mesh_prov_link_close_reason_t reason), the reason is always 0x02 error.)
-> prov_cb_link_closed(prov_bearer_t * p_bearer, nrf_mesh_prov_link_close_reason_t close_reason) (AKA prov_provisioner_cb_link_closed(prov_bearer_t * p_bearer, nrf_mesh_prov_link_close_reason_t reason))
in which an event with the type "NRF_MESH_EVT_PROV_LINK_CLOSED" will be pushed into the event queue and the program will keep running till it reaches:
mesh_evt_handler 's
case NRF_MESH_EVT_PROV_LINK_CLOSED
, and go to :
m_prov_state = PROV_STATE_WAIT;
Now... the obvious question: what do I do now? I'm positive my provisionee/server boards/nodes are responding, because the program won't go to above mentioned places at all if none of the nodes were turned on.
@thomasstenersen
@bjorn-spockeli
@joh2
Help...?
Edit #2:
So I plugged in the provisionee/server board, and found out that it keeps sending prov failure in the RTT window, and sure enough, I found the culprit, but before I list it here, a call stack tree first:
So why send_failed was called? Apparently it meets this standard:
if(!prov_utils_confirmation_check(p_ctx))
in
prov_provisionee_pkt_in function.
Now, naturally I looked into the "prov_utils_confirmation_check(p_ctx)" fucntion and did a little modification (nothing major, don't worry) to make my life easier, things went wrong at this line:
ble_mesh_v0.9.1-Alpha\mesh\src\prov\prov_utils.c:
line 341:
int result = memcmp(confirmation, p_ctx->peer_confirmation, sizeof(confirmation)) == 0;
return result;
the result is 0, indicating that everything is alright.
But when it returns, since there is an "!" mark involved in the if, 0 gets turned into a 1.
I'm kind of confused: it isn't supposed to be 0? The size compared should be different? Why?