Hi Fotis,
>NuttX is not able to boot at all with this option selected. I stepped >through the code and it seems that nxsig_initialize actually causes a stack >overflow that is detected by the above check. >Is this a bug, or I should configure something in a different way? Have you seen https://cwiki.apache.org/confluence/display/NUTTX/ARMv7-M+Run+Time+Stack+Checking We have this working in PX4. 'make px4_fmuv5_stackcheck' as of NuttX master a few weeks ago You can see it passing on the hardware test rack the last entry is px4_fmu-v5_stackcheck http://ci.px4.io:8080/blue/organizations/jenkins/PX4_misc%2FFirmware-hardware/detail/master/2374/pipeline It is most likely a configuration and build issue. (Albet the SW stack coloring is broken on master and under repair curretly) The __stack_overflow_trap should carry __attribute__ ((no_instrument_function)) Also R10 has to be preserved. All files built in the build have to have the same CONFIG_ARMV7M_STACKCHECK settings. The margin is artificially set. Are you using a separate interrupt stack? With a lot of the new changes, we can assume the init path's nesting level has not been kept small. Increase the idle stack size by a lot (1024) and retest. David -----Original Message----- From: Fotis Panagiotopoulos [mailto:f.j.pa...@gmail.com] Sent: Tuesday, October 06, 2020 12:40 PM To: dev@nuttx.apache.org Subject: Stack overflow during system init. Hi everyone, I just enabled CONFIG_ARMV7M_STACKCHECK, as I would like to have this functionality in my project, but I am facing problems. NuttX is not able to boot at all with this option selected. I stepped through the code and it seems that nxsig_initialize actually causes a stack overflow that is detected by the above check. Is this a bug, or I should configure something in a different way? Then I realized that __stack_overflow_trap is broken. When a stack overflow happens, this function is called which is supposed to cause a hardfault. However as __stack_overflow_trap is a function itself, __cyg_profile_func_enter is called again. Once again it detects the overflow and calls __stack_overflow_trap, and so on... Finally, as I see, the stack check is performed while entering a function, which is wrong. If there is a stack overflow, it will be detected at the next function call, which may be at a irrelevant part of the code. I believe that the check shall be performed on the exit of a function, in which case you will be sure that this specific function caused the overflow. And of course it will solve the issue above with __stack_overflow_trap.
