Hello, when trying to finish provisioning my nodes (3 total, per example program's instructions), my provisioner program keeps running into
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
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
, most likely when executing
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:
, 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.
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:
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:
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?