ChibiOS Free Embedded RTOS

Developing on an STM32L152RE Nucleo, I have observed the following strange behavior:
I am reading audio data from an SD card and writing the same to I2S. I currently have only one thread, which reads the data from the card. The (ISR-triggered) I2S callback then requests reading the next chunk of data, using a semaphore.
Elm Chan´s implementation uses quite some stack, with 0x4000 (16 kB) for stack it runs all fine as long as I run it in the main thread.
As soon as I move the same code into a separate thread with a working area of the same size (16kB), I run into a stack overflow assertion. Even increasing to about 50kB did not help.
Buffers are in .bss, not on the stack. The stack trace is quite long, but this does not explain a) what happens at all b) why the behavior is different between forked thread and main thread.
Looking at the stack pointer register, it points to <playThread+15248> - so a stack overflow should still be 15.2 kB away.

I would be glad to be enlightened what is going wrong here.

Thank you,

Max

Hi,

The behavior should not be different, main thread is a thread like the others except for stack allocation.

Perhaps the stack is not at the limit in the moment you observe it. Enable stack filler and look at the working area (or use the ChibiOS plugin in ChibiStudio if you are using it).

Are you sure it is just FatFS using so much stack? in that stack trace it is called by other functions, not just main.

BTW, this forum is not for support, moving this topic.

Giovanni

Hi Giovanni,

sorry for leaving out some details.

• The moment of observation is after the program has run into the stack overflow assertion
• Using the CH_DBG_FILL_THREADS option, I can see that there is plenty of room left. The lowermost entry is about 150 bytes below the stack pointer at the time of the failed assertion. In other words: there is about 15kB of RAM which has not been used.
• The "other function" is the thread that I have created (play_thread). This calls play(), which in turn calls f_read() (from Elm Chan), which then resorts back to ChibiOS code (disk_read() and anything beyond).

The only other thread is main(), which is idling around. Can you give me a hint how the stack overflow detection roughly works? Then I can start investigating.

I had observed some similar behavior recently in a different program when using event signalling. As I could solve it by using a semaphore instead, I did not check further.

Thank you,

Max

Hi,

Stack checking happens at context switch time, before pushing the thread registers in the stack a check is performed, look at the port_switch() function, note that in your stack trace the halt happens on thread suspend.

You can also enable an alternative stack check method using the MPU, look at the port options for that.

Giovanni