Stack Sizes

[Scott Symes]

I’ve been having issues with stack overflow with my xDot application. Even after specifying a stack size as suggested in the docs under “Limited System Memory” (just above this link) and creating a thread

uint8_t t1_stack[1536]; // xDot main thread/other threads: 1.5kB/256B 

Thread main_thread(osPriorityNormal, sizeof(t1_stack), t1_stack);

I’ve incorporated a printout of the memory map and threads into the code

threadId: 2000106c, stack_start: 200014e0, stack_end: 20001800, size: 800
threadId: 200010ac, stack_start: 20001b60, stack_end: 20002160, size: 1536
threadId: 200010ec, stack_start: 20000720, stack_end: 20000d20, size: 1536
threadId: 2000112c, stack_start: 2000326c, stack_end: 20003c6c, size: 2560
threadId: 200021a0, stack_start: 20001240, stack_end: 20001240, size: 0
 mbed_heap_start: 2000283c, mbed_heap_end: 20007e00, size: 21956
 mbed_stack_isr_start: 20007e00, mbed_stack_isr_end: 20008000, size: 512
             
threadId: 2000106c, entry: 0801c195, osThreadInfoState: 4, osThreadInfoStackSize: 800, osThreadInfoStackMax:  4
threadId: 200010ac, entry: 0801cd05, osThreadInfoState: 4, osThreadInfoStackSize: 1536, osThreadInfoStackMax:  4
threadId: 200010ec, entry: 08018085, osThreadInfoState: 4, osThreadInfoStackSize: 1536, osThreadInfoStackMax:  4
threadId: 2000112c, entry: 08018085, osThreadInfoState: 4, osThreadInfoStackSize: 2560, osThreadInfoStackMax:  4
threadId: 200021a0, entry: 0801c221, osThreadInfoState: 4, osThreadInfoStackSize: 512, osThreadInfoStackMax:  4

Looking at the thread data above: As there are multiple threads spawned (including one of 2560 bytes), is it possible to configure the stack sizes for the entire program in mbed_app.json rather than by creating extra threads in main? That is, is it possible to override the mbed defaults another way?

In trying to debug this, the next thing is to compile locally with the mbed CLI to generate an ELF file to be able to work out which thread entry point corresponds to which function. The trouble is, compiling with mbed CLI and the GCC_ARM toolchain creates multiple “undefined reference” linking errors. Is this to do with incorrectly linking in the ‘libxDot-GCC_ARM.a’ binary? I’ve tried using both my own program (utilising xDot-dev) and the Multitech Dot-Examples (using the stable xDot library), both with the same problem. Would switching to the ARM compiler fix this issue?

For these compile tests I have been using the latest libxDot-mbed5, mbed-os 5.4.7 and GCC_ARM 6.3.1 (2017-q2-update)

[Leon Lindenfelser]

Hi Scott,

To adjust the stack sizes look in the file “…mbed-os\rtos\rtx\target_cortex_m\Cmsis_os.h” line 89 you should see:

#define DEFAULT_STACK_SIZE (WORDS_STACK_SIZE/2)

WORDS_STACK_SIZE is 512 so this sets DEFAULT_STACK_SIZE to 256.

In the file “…mbed-os\rtos\rtx\target_cortex_m\RTX_CM_lib.h” line 363 you should see:

static uint32_t thread_stack_main[DEFAULT_STACK_SIZE * 6 / sizeof(uint32_t)];

This sets the stack for the main thread to 1.5k.

As for your offline compiling issues, please try using an older GCC_ARM compiler version. mbed-cli used to call out using a GCC_ARM version < 5.0. I have been using version 4.9 2015q2. If I recall correctly, you want to use GCC_ARM compiler versions < 5.0 for mbed-os versions < 5.5.0. Kind regards, Leon

[Author]

Posts