Idle Stack Overflow Issue

[AGlass0fMilk]

Description

Target: NRF52_DK
Toolchain: GCC ARM (arm-none-eabi-g++ (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437])
SHA of Mbed OS: 866850a Merge pull request #7171 from ARMmbed/release-candidate

I am having a strange issue while developing on the NRF52_DK platform. I am starting to play around with a graphics library, LittleVGL, and porting it to mbed. I have set up a test main.cpp to get started, but my code encounters an error and prints out the following:

++ MbedOS Error Info ++
Error Status: 0x80020125 Code: 293 Module: 2
Error Message: CMSIS-RTOS error: Stack overflow
Location: 0x43d7d
Error Value: 0x1
Current Thread: Id: 0x200059b0 Entry: 0x45915 StackSize: 0x100 StackMem: 0x20005a40 SP: 
0x2000fed8
-- MbedOS Error Info --

It seems to be the idle thread stack is overflowing (main thread stack size is 0x1000 by default, so it can't be the main thread)

The strange part is, my code doesn't execute anything from the libraries at this point. Perhaps it's static initialization or something.

The code causing this issue is:

#include "mbed_wait_api.h"
int main(void)
{
  int i = 0;
  wait_ms(100);
  i++;
  wait_ms(50);
  i++;
  while(1)
    {
      wait_ms(500);
    }
}

That's it. I don't make any calls to the library at all, I haven't even #included it.

I have encountered this issue before, but I have been able to increase the idle thread stack size by modifying mbed_rtx.h... but a recent update removed the macro I previously used to do this...

So now I'm not sure how to fix this issue. What could be going wrong?

Issue request type

[ ] Question
[ ] Enhancement
[ X ] Bug

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-711

[SenRamakri]

@AGlass0fMilk - Is it possible for you to attach .map/.elf files for the build which is exhibiting this problem?

[SenRamakri]

@AGlass0fMilk - I tried to run your main.cpp on my NRF52_DK and Im unable to reproduce the problem. It runs just fine. And I have the same tool chain version as well(arm-none-eabi-g++.exe (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release) [ARM/embedded-6-branch revision 249437]).
So, having .elf/.map might help us debug the problem.

[SenRamakri]

@AGlass0fMilk - We haven't received any response in this issue. Please let us know if the issue is resolved otherwise.

[AGlass0fMilk]

Sorry for the delayed response, I haven't been working with this code for a few days.

The issue seemed to be caused by external hardware in some manner... I encounter this issue every now and then. Is there a way to increase the idle thread stack size using the mbed compile time configuration tools?

EDIT: There seems to be a thread for a similar issue on ST targets. I am a bit busy right now to try and reproduce this issue but I will update if I see anything else occur.

[SenRamakri]

@AGlass0fMilk - Yes you can either specify that in mbed_lib.json under rtos/ folder using idle-thread-stack-size or use -DMBED_CONF_APP_IDLE_THREAD_STACK_SIZE= in your command line. And if this is confirmed to be something caused by external hw please close this issue.

[LMESTM]

@SenRamakri similar error has been reported in #7235. This happens if using non optimized profiles (debug / developer) and also needs activating TICKLESS and various STATS options as reported by @janjongboom
What I found so far is that the overflow seems to happen in default idle hook - not sure where, but it seems to be somewhere else than targets' hal_sleep or hal_deepsleep functions.
If stack size usage cannot be optimized, this seems this can be fixed by increasing idle stack size from 512 to more or less 544 ... but I think this may need to be looked at by mbed core team.

[AGlass0fMilk]

Note: This issue was occurring with the debug build profile.

[LMESTM]

@0xc0170 I think this issue is reproduced on DISCO_F413ZH and is blocking @janjongboom

[deepikabhavnani]

@AGlass0fMilk - Please confirm if increasing idle thread stack size resolves the issue?

The issue seemed to be caused by external hardware in some manner...

Please explain this, what hardware and how?

[janjongboom]

@deepikabhavnani Yes, increasing idle thread stack size helped, but I think the underlying issue was fixed.