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

[Amanda Hsieh]

Hi Denis, 

It needs to check the fault output, which states the thread address, and match this address with the one in the build-folder/zephyr/zephyr.map and try to adjust the related stack size. 

-Amanda H.

[denis]

You seem to be saying that we should just wait for faults and then add more stack size until we don't see faults?  For undocumented threads created by modules that are provided by NCS, and not our application?  Is that correct?

Any answer for "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?"

[Amanda Hsieh]

(Updated)

denis said:

"The CONFIG_BT_HCI_TX_STACK_SIZE does not seem to take effect though, it is 1024 instead of 4096.  Any idea why?

You also need to set CONFIG_BT_HCI_TX_STACK_SIZE_WITH_PROMPT=y. See CONFIG_BT_HCI_TX_STACK_SIZE doc.

--

Hi Denis, 

denis said:

that we should just wait for faults and then add more stack size until we don't see faults?

 Check out this: http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/app_memory.html

You can tune the stack sizes with Thread analyzer and puncover.

 

denis said:

any debug tips on how to tell where and why a config value ends up with its final value after merging

 You can check the <sample>/build/zephyr/.config

-Amanda H.

[denis]

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).

[CktDesigner]

Agree 100%