Using more handles results in zombie nodes

[vliedel]

Hi, I'm testing out using more handles, but it seems to result in zombie nodes. When attaching the debugger, it always seemed to end up in order_next_transmission from version_handler.c.

I was thinking it might have something to do with these settings: RBC_MESH_HANDLE_CACHE_ENTRIES RBC_MESH_DATA_CACHE_ENTRIES RBC_MESH_APP_EVENT_QUEUE_LENGTH RBC_MESH_RADIO_QUEUE_LENGTH RBC_MESH_INTERNAL_EVENT_QUEUE_LENGTH As, at some point I tried to minimize those (to save RAM), but that also led to zombie nodes.

Btw: I'm on the sdk8 branch, but with radio_control.c from the dfu branch.

[vliedel]

Hm it seems to happen with just 1 handle too.

[daviddedwin]

Can you provide more information on your mesh settings and packet sizes so we can re-produce the issue ?

[vliedel]

Hey, at the moment the mesh seems to be in such a state that my "sink" node goes zombie after a few minutes (I regard it as zombie when I don't see anything on UART, and I can't connect to it anymore, it sometimes still advertises though). Most nodes (24 in total) are still sending new data.

All nodes are also advertising, and all nodes except for the sink node are also scanning at regular intervals.

Here is my config, only showing the non-default:

    NRF_RADIO->PCNF0 =  (
                          (((1UL) << RADIO_PCNF0_S0LEN_Pos) & RADIO_PCNF0_S0LEN_Msk)    // length of S0 field in bytes 0-1.
                        | (((1UL) << RADIO_PCNF0_S1LEN_Pos) & RADIO_PCNF0_S1LEN_Msk)    // length of S1 field in bits 0-8.
                        | (((7UL) << RADIO_PCNF0_LFLEN_Pos) & RADIO_PCNF0_LFLEN_Msk)    // length of length field in bits 0-8.
                      );

    NRF_RADIO->PCNF1 =  (
                          (((113UL)                         << RADIO_PCNF1_MAXLEN_Pos)  & RADIO_PCNF1_MAXLEN_Msk)   // BLE_ADV_PACKET_PAYLOAD_MAX_LENGTH + 6
                        | (((0UL)                           << RADIO_PCNF1_STATLEN_Pos) & RADIO_PCNF1_STATLEN_Msk)  // expand the payload with N bytes in addition to LENGTH [0-255]
                        | (((3UL)                           << RADIO_PCNF1_BALEN_Pos)   & RADIO_PCNF1_BALEN_Msk)    // base address length in number of bytes.
                        | (((RADIO_PCNF1_ENDIAN_Little)     << RADIO_PCNF1_ENDIAN_Pos)  & RADIO_PCNF1_ENDIAN_Msk)   // endianess of the S0, LENGTH, S1 and PAYLOAD fields.
                        | (((RADIO_PCNF1_WHITEEN_Enabled)   << RADIO_PCNF1_WHITEEN_Pos) & RADIO_PCNF1_WHITEEN_Msk)  // enable packet whitening
                      );

#define RBC_MESH_VALUE_MAX_LEN           (99)
#define BLE_ADV_PACKET_PAYLOAD_MAX_LENGTH   (RBC_MESH_VALUE_MAX_LEN + 1 + MESH_PACKET_ADV_OVERHEAD)
#define MESH_ACCESS_ADDR 0xA541A68E
#define MESH_INTERVAL_MIN_MS 100
#define MESH_CHANNEL 38
#define MESH_CLOCK_SOURCE NRF_CLOCK_LFCLKSRC_RC_250_PPM_TEMP_8000MS_CALIBRATION

[trond-snekvik]

Is this still persistent in the newest updates?

[vliedel]

It hasn't happened in a setup of 11 nodes with 2 handles, which has been running for months now :)