• State Verified Answer
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 77 subscribers
  • Views 10207 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 265143
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Zephyr stack size configurations

denis

I've added some debug information to the build of my application.  The added stack usage has caused some threads (USB, BLE) to overflow the stack and cause random crashes.  How can we tell what threads will be created and what stack sizes are needed when various config options are set?

I've been looking in the SES threads view (after creating a threads script) to look at the stack sizes, then just making most stack sizes much larger.  Some of the config options I'm trying are shown below.  Most take effect.  The CONFIG_BT_HCI_TX_STACK_SIZE does not seem to take effect though, it is 1024 instead of 4096.  Any idea why?  Or any debug tips on how to tell where and why a config value ends up with its final value after merging?

CONFIG_NO_OPTIMIZATIONS=y
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_THREAD_MONITOR=y
CONFIG_THREAD_STACK_INFO=y
CONFIG_THREAD_NAME=y

CONFIG_MAIN_STACK_SIZE=4096
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_USB_NRFX_WORK_QUEUE_STACK_SIZE=4096
CONFIG_USB_WORKQUEUE_STACK_SIZE=4096
CONFIG_BT_RX_STACK_SIZE=4096
CONFIG_BT_HCI_TX_STACK_SIZE=4096
CONFIG_BT_RPMSG_NRF53_RX_STACK_SIZE=4096

Parents
  • 0

    This continues to be an issue in NCS 2.0.0.

    In addition to the above I had to add:

    CONFIG_MPSL_WORK_STACK_SIZE=4096
    There is another stack size that I can't increase via the prj.conf: CONFIG_BT_CTLR_ECDH_STACK_SIZE.
    I recall seeing some comments that these threads are implementation details users should not know about and should not be able to tune.  This seems obviously incorrect, since we do have to change them.  One of the main goals of Zephyr is that it is configured for the features of each specific application.  The philosophy of hiding the fact that threads are being created and being able to configure them seems to go directly against that.  And as seen here, these need to be customizable based on compilation options.
    I believe that the philosophy should be that for subsystems like BLE, USB, etc, that use threads:
    1) The threading model should be documented.  What are the threads?  How do they interact with each other and with any user threads?  Are there constraints for the user threads (priority, etc)?
    2) Each specific thread should be documented.  The name of the thread, the default stack size, the priority, any considerations for setting time slice size, etc.
    3) Minimally the stack size should be configurable.
    4) Possibly consider at least configuring the thread sizes larger when certain options are used (
    CONFIG_NO_OPTIMIZATIONS=y for example).
Reply
  • 0

    This continues to be an issue in NCS 2.0.0.

    In addition to the above I had to add:

    CONFIG_MPSL_WORK_STACK_SIZE=4096
    There is another stack size that I can't increase via the prj.conf: CONFIG_BT_CTLR_ECDH_STACK_SIZE.
    I recall seeing some comments that these threads are implementation details users should not know about and should not be able to tune.  This seems obviously incorrect, since we do have to change them.  One of the main goals of Zephyr is that it is configured for the features of each specific application.  The philosophy of hiding the fact that threads are being created and being able to configure them seems to go directly against that.  And as seen here, these need to be customizable based on compilation options.
    I believe that the philosophy should be that for subsystems like BLE, USB, etc, that use threads:
    1) The threading model should be documented.  What are the threads?  How do they interact with each other and with any user threads?  Are there constraints for the user threads (priority, etc)?
    2) Each specific thread should be documented.  The name of the thread, the default stack size, the priority, any considerations for setting time slice size, etc.
    3) Minimally the stack size should be configurable.
    4) Possibly consider at least configuring the thread sizes larger when certain options are used (
    CONFIG_NO_OPTIMIZATIONS=y for example).
Children
Related
Terms of service