NordicPlayground / nRF51-ble-bcast-mesh

Other
323 stars 121 forks source link

Help! Mesh packet pool overflow? #167

Closed bayou9 closed 7 years ago

bayou9 commented 7 years ago

Hello, I'm now being stonewalled by this problem: the function

mesh_packet_acquire()

keeps returning no memory error.

I placed a counter inside the function to see if it's a programmatic error (for example, mesh packets are not being released at all) or if it's because the pool wasn't set to be big enough, and the code looks like this:

bool mesh_packet_acquire(mesh_packet_t** pp_packet)

{ uint32_t was_masked;

for (uint32_t i = 0; i < RBC_MESH_PACKET_POOL_SIZE; ++i)
{
    _DISABLE_IRQS(was_masked);
    if (g_packet_refs[i] == 0) /* no refs, free to use */
    {                        //This is how things work:loop through all packet refs to see if it's 
        g_packet_refs[i] = 1;//a 0. If it is, then set it to 1, meaning it's claimed.

#ifdef DEBUG

    if (1)
    {
        counter++;
    }

#endif  

                *pp_packet = &g_packet_pool[i];//now that above steps had acquired the proper, free index number i, we can allocate a pointer to point at it.
        _ENABLE_IRQS(was_masked);
        return true;
    }
    _ENABLE_IRQS(was_masked);
}
APP_ERROR_CHECK(NRF_ERROR_NO_MEM);
return false;
}

as you can see, "counter" is the... counter. When the program hit the breakpoint I set inside "app_error_handler" (which will execute as soon as the NRF_ERROR_NO_MEM gets returned), the counter stopped at a variety of random values, e.g. 0x15B, which is 347, or 0x149, which is 329, most values are around 320. Which means that memories in the packet pool are being ordered, then released, ordered then released etc. until it reaches the max pool size.

What is going on? Is this anticipated? How big should I configure the pool? Honestly I hope this program can run unadministered forever! Please help?

Edit: It appears that this overflow is caused by order_search which is passed by radio_idle_callback to radio_event_handler.

I modified the program to let the counter hit 200 and see what has been invoking the mesh_packet_acquire all along, it turns out the for the most time the culprit (the function that keeps acquiring mesh packets) is order_search, (although I'm not sure if it is always the case, I haven't done enough experiment, i.e. set the counter value to stop at 150, 151, 152...) but I'm pretty confident it is the case.

trond-snekvik commented 7 years ago

Closing as duplicate of #169, as discussion has been started there. Please reopen if this is a different issue.