Unexpected event:24

RE: Unexpected event:24

Hung Bui — Fri, 29 Sep 2017 10:12:06 GMT

The result doesn't make much sense. Could you send the .elf file of the server ? Do you have any modification of the source code ? You mean the first server get configured has no problem but the 2nd and 3rd has ?

RE: Unexpected event:24

rahul — Fri, 29 Sep 2017 10:07:31 GMT

Also I'm not able to understand how the error occurs after the two devices have been successfully configured and when the chips were erased before loading the respective codes to prevent any sort of persistent storage issues.

RE: Unexpected event:24

rahul — Fri, 29 Sep 2017 10:05:04 GMT

I'm aware where the fault is happening and that the servers aren't responding. The ASSERT happens upon multiple calls from the server and immediately after the client is switched on. I would like to know how i could fix this issue. rgds rahul

RE: Unexpected event:24

rahul — Fri, 29 Sep 2017 09:56:30 GMT

I receive this error everytime the server count is greater than 1. Also entering it into addr2line gave: 681B ldr r3, [r3]

RE: Unexpected event:24

Hung Bui — Fri, 29 Sep 2017 08:42:39 GMT

As Faik mentioned event 24 is "NRF_MESH_EVT_SAR_FAILED". It may not related to the provisioner. As you can see in the log, the provisioning was finished before the unexpected event. It could be just a corrupted SAR packet or a packet didn't receive an ACK.

Regarding <t: 876132>, nrf_mesh_node_config.c, 112, MESH ASSERT at 0x00023242, How often do you receive this ? Do you get this on all 3 servers or not ? Could you use addr2line to translate 0x00023242 to address ? Syntax should be: addr2line -e light_control_server.elf 0x23343

RE: Unexpected event:24

Faik — Fri, 29 Sep 2017 08:05:40 GMT

Hi,

Event 24 is "NRF_MESH_EVT_SAR_FAILED". There is also a reason for the failure which you can find by inspecting p_evt.

add the following to your code:

case NRF_MESH_EVT_SAR_FAILED:
__LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "SAR FAILED: packet %u, reason %u\n", p_evt->params.sar_failed.packet_id, p_evt->params.sar_failed.reason);
break;

In your case the failure reason is probably

NRF_MESH_SAR_CANCEL_REASON_RETRY

As you can see in the logs there are many TX's but no RX. your server is not responding to the requests sent by the client and the client is trying to resend them until it hits a limit, and that seems to be because your server has stoped working (see the MESH_ASSERT in your logs.) You should check where the ASSERT is happening.

Br Faik