ESP32 Forum

Hi,

I've compiled a firmware and had it run on multiple devices without any sort of issue, but have found 1 which was stuck in a continuous reset loop.

On further investigation the cause was found. When a particular task was created using the xTaskCreatePinnedToCore() function, an error code of -1 would be returned. The firmware is designed to reset whenever a task cannot be created, assuming that something went wrong during program execution.

I've run heap_caps_get_largest_free_block(MALLOC_CAP_8BIT|MALLOC_CAP_INTERNAL) to find out how much contiguous internal DRAM I have available for stack allocation and have found it to be low. Reducing the stack depth of the task the RTOS is attempting to create solves the reset issue.

What's puzzling me is why this happened on a single device, but not on the rest. I've had 3 other devices undergoing extensive testing and none gave any hint of such an issue. Is there something I'm missing, such as perhaps variances in the order of a few kB in the available internal DRAM between one ESP32 and another?

Is this on initialization, or has the ESP32 already been running for a while after the WiFi stack has been initialized? If the second, the difference could be that some WiFi activity already has depleted the stack by a bit. (Another thing I can think of is that the chips may be a different ECO, although I'm not sure if that would show in an allocation size change.)

This is during initialization, just after the WiFi stack has been initialized.

Please forgive what might be an obvious question, but what do you mean by different ECO?

The ESP32 has various revisions (you'll find ECO0, 1 and 3 in the wild) that fix various bugs. Workaround for some bugs may use some dynamic memory ('may' as I can't easily check here) that affect memory allocation. Shouldn't be much, but can be just enough to push you over the edge, as it were.

I see. Well, all the boards (custom made boards) being tested use the WROVER-IE, which should have the same ECO version.

But your earlier point regarding the WiFi stack has put a bug in my ear I'll try checking how the amount of un-allocated memory varies between different boards both with and without the WiFi stack initialized to see whether that's the source of the different behavior.

I've found the root of the issue! It has nothing to do with the ESP32's memory and everything to do with my firmware A TCP Client was being initialized twice in the device which kept rebooting, resulting in the lower amount of unallocated memory on it.

Thanks for your support!

No problem, thanks for reporting back on this!