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:
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.
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:
{ uint32_t was_masked;
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.