What happen if i call recursivley a method like that:
// Calls a function x times, this functions allocates 1k in the stack
// then i call the function again
void callProc(int x){
// I allocate around 1kb as local variables then it should go in the stack
size_8t vector[1000];
Serial.print("I have allocated 1kb in the stack");
// I repeat the allocation, calling recoursivley callProc(x-1) times
if (x>=2){
callProc(x - 1);
// I just add this code to prevent the code optimization on the allocation of my array
for (int i=0; i<999;i++){
vector[i+1] = vector[i];
}
} else {
return;
}
}
The code is not well written but it is very simple, I have the right version on my pc but I'm not at home
Well on the esp32 -an az-delivery board- (i should have 500k of ram) it happen that the microcontroller call tha procedure about 5 or 6 times and after it reset. It should not be a memory issue since for 6 times the memory used is around 6K.
I've tried to run it on an raspberry pi pico and it works as I expected.
Do you have any suggestions? How I can solve the problem?
All the issue was born when i tried to compile a library and flash it on a arduino iot 33 nano. It did not worked, then I tried again on the esp32 but it did not worked, then I tried again with an raspberry pi pico and it worked.
The section you posted in is not for your project is when you are having problems installing the IDE on your system.
I have moved it here which is a better place to ask about recursion.
Posting all your code is much more useful than just posting a bit, we can't see the overall structure or try it ourselves.
The ESP32 uses a version of FreeRTOS and supports multiple tasks/threads. Each task has its own stack, and stacks are actually allocated on the heap. The default stack size for the setup and loop is defined in
I'm not familiar with the specific memory layout for the Pi Pico, but I suspect it has a single stack that can grow much larger, probably until hitting the top of the heap.
Moral of the story: don't allocate large arrays on the stack.
I think you got the point. An observation that could make me think you are right is because the board works until around 8k and is the same amount of memory consumed during my test.
Decoding stack results
0x400887bc: xQueueSemaphoreTake at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/queue.c line 1535
0x400d2fef: uart_tx_all at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/driver/uart.c line 1186
0x400d384d: uart_write_bytes at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/driver/uart.c line 1246
0x400d1d50: uartWriteBuf at C:\Users\giana\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.3\cores\esp32\esp32-hal-uart.c line 310
0x400d111d: HardwareSerial::write(unsigned char const*, unsigned int) at C:\Users\giana\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.3\cores\esp32\HardwareSerial.cpp line 461
0x400d1507: Print::write(char const*) at C:\Users\giana\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.3\cores\esp32/Print.h line 67
0x400d1519: Print::print(char const*) at C:\Users\giana\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.3\cores\esp32\Print.cpp line 89
0x400d0f5c: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 8
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0f72: callRec1000(int) at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 11
0x400d0fe6: setup() at C:\Users\giana\OneDrive\Code\Arduino\callRec\callRec/callRec.ino line 28
0x400d18b6: loopTask(void*) at C:\Users\giana\AppData\Local\Arduino15\packages\esp32\hardware\esp32\2.0.3\cores\esp32\main.cpp line 42
Here you can see the high water mark function
As you can see the stack size become smaller and smaller, as expected.
I don't think is a matter of numbers of call but is a problem of stack size
I have a library and i need to modify the library making malloc() and (unfortunatley) free() when i return()
It's a great idea modify the stack prior to the creation of the task. I think i should increase the ARDUINO task.
I've seen the link but where i can put the call to the function? If i call them in the start(){} i'm allredy in the task then i cannot use the functions? Or i can and modify the task's stack?
In other words, the maximum stack size is 64KiB-1byte = 65535 bytes.
You should never use malloc in C++. And if you need dynamic allocation, you should probably be using containers or smart pointers like std::unique_ptr so you never have to worry about manually deallocating them.
i don't want introduce errors in my library.
The library you're using should include a comprehensive testing suite so you can be confident that it still works after changes like this.
The line you quoted doesn't mean anything in isolation, AFAIK, it is only meaningful for Load/StoreProhibited exceptions.
The error here is the stack canary being triggered.
Please read the posts earlier in the thread before cluttering it with unrelated code snippets, OP is already logging uxTaskGetStackHighWaterMark.