Stack size question

[Tectu]

Hello Folks,

After I fixed all the issues I had at the beginning with ChibiOS, I have a question related to the stack and heap.
First, you should notice that I am new to this stuff and just have basic knowledge about things like heap grows upwards, stack downwards etc. etc.

I took the FATFS example for the STM32F103 and ported it to my own board. I can run the test benchmark over the shell etc. I didn't change anything, there's just running the blinker thread, the shell and the fatfs itself. After doing BYTE buffer[4096] in a function which should write to a file on the SD card, the chip run into an unhandled expection whenever I called that function which uses that buffer afterwards with strcpy (the mcu dosen't crash when I call the function I wrote myself, it crashes at the strcpy() call inside that function). After some register viewing, I found out that the stack pointer has the value: 0x20000400 which might be the bottom of the stack.
So, here's my question: I have a STM32F103VET on my board, that thing does have 64kB of SDRAM. Does ChibiOS use so much memory, that I cannot get even 4k of stack in a program, which does nothing beside blinking an LED, running the shell and FATFS?
As I said, I am pretty new to the whole field of embedded stuff. Could it be, that I am doing something horribly wrong, or that I have to set stack limits etc. in ChibiOS?
I could only find the debug and check triggers in chconfig.h.

This is my function:

Code: Select all

static void cmd_write(BaseSequentialStream *chp) {
    FRESULT ferr;
    FIL fdst;
    UINT written;
    BYTE buffer[64];


    ferr = f_open(&fdst, "0:log.txt", FA_CREATE_ALWAYS | FA_WRITE | FA_READ);
    if(ferr != FR_OK) {
        chprintf(chp, "f_open() failed!\r\n");
        return;
    }   

    strcpy(buffer, "Hello World!");
    f_write(&fdst, buffer, sizeof(buffer), &written);

    f_close(&fdst);

    return;
}


This works that way, but when I do BYTE buffer[4096], it crashes at the strcpy().

What can you tell me to this?

I use this toolchain: https://launchpad.net/gcc-arm-embedded


~ Tectu

[Giovanni]

Each thread has its own separate stack, so you need to give each thread enough space. This is the most critical thing when doing multithreaded embedded programming.

Automatic variables are allocated in the function stack frame so if you allocate 4KB inside a function then all threads calling that function must have enough space in their own stack.

More info in this page: http://www.chibios.org/dokuwiki/doku.ph ... :kb:stacks

Giovanni

[mabl]

Depending on your design you could also make the array static and protect it with a mutex if necessary.

[Tectu]

Thanks for the link, Givoanni. I read that article before I created this topic.

My question is in that case:
I know how to create a basic thread, and give it a stacksize / workspace. But when we take the STM32F103-FATFS example, where do I set the size for functions like cmd_tree, or other fuctions which are getting called over the shell?

I saw the macro #define SHELL_WA_SIZE THD_WA_SIZE(4096) but i am not sure if this is just the shell itself, or also the "calls" which are listed in the commands[] array.

Also: When I type "tree" into the shell, will the function cmd_tree be executed as a single thread, or within the shell thread?


~ Tectu

[Giovanni]

The thread stack must be large enough to include the space require by all functions called from the thread context, so if you thread A call a function that requires 4096 bytes then the working area of A must be larger than 4096, probably significantly larger.

In general a thread stack must be large enough to include the worst case usage of your functions call tree.

BTW, allocating large arrays in stack is a bad practice.

Giovanni

[Tectu]

So, I am right when I say that every function in the commands[] array which can be called through the shell is in the stack defined as #define SHELL_WA_SIZE THD_WA_SIZE(4096) ?

BTW, allocating large arrays in stack is a bad practice.Giovanni

How to do the right way?

[Giovanni]

There are lots of possible solutions:
1) Use a static buffer, if you need to access if from multiple threads then use mutual exclusion.
2) Use a memory pool of buffers: allocate, use, release.
3) Allocate from the heap (slower).

It depends on what you want to do.

Giovanni

[mabl]

Or find a solution which does not require that much memory

You could also make your function work on a given buffer, than you can handle the buffer differently from calling locations.

[Tectu]

I see.

Is there any ChibiOS support for "Use a memory pool of buffers: allocate, use, release.", or am I supposed to write that up from scratch?

Also, "Allocate from the heap (slower).", like using malloc() on x86?

[mabl]

This is all included in ChibiOS have a look into the fine manual.

Also, "Allocate from the heap (slower).", like using malloc() on x86?

Of course allocating different size objects is slower than a pool of same size objects.