This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Disable optimization of part of the code through CMAKE

Hi,

A simple CMAKE question, somewhat regarding the zephyr build, but pretty essential for someone using JTAG to debug the application:

How does one disable optimization (-Os) for just a few files in the zephyr build?

I quicky tried a few things in the CMakeLists.txt:

- Adding a global target_compile_options(-O0) option => Builds the entire thing (incl zephyr) with O0, causing 200kB flash overflow

- Using target_compile_options(app PRIVATE -O0) => Leads to -O0 option, but this is overridden later in the compile line by -Os again, causing this to be negated

There must be a simple way to overrule Zephyr's overuling of the optimization compile option, and I am hoping somebody can quickly answer me on this.

Thanks!

  •  (The compile line, split into verticial lines, of e.g. main.c in asset_tracker, when adding target_compile_options(app PRIVATE -O0)

  • Hello, Arnout!

    I've asked internally about this, but there seems to be some difficulties with optimization flags passed from CMake as stated in this issue on the Zephyr RTOS GitHub. Have you tried the CONFIG_NO_OPTIMIZATIONS option in prj.conf?

    Edit: a colleague said that they have been using the following solution in a bit different context:

    add_library(set-app-flags INTERFACE)
    target_compile_options(set-app-flags INTERFACE -O0)
    target_link_libraries(app PRIVATE set-app-flags)


    Best regards,
    Carl Richard

  • Hi Carl,

    Nice! Adding the last 3 lines to the root CMakeList.txt file magically fix it indeed. It adds the -O0 parameter at the end for all app-compiled files, and not for the rest -- exactly what I wanted to do.

    Thanks for the help!

    Kind regards,

    Arnout

  • By the way, just for info, I actually -tried running- this code now (asset_tracker from sdk 1.6.0, compiled with -O0)

    This crashes at boot now, seems to be a stack overflow. (Makes sense, given the new compilation options).

    You don't happen to know by heart how to increase the thread stack sizes? :)

    If not, I think I'll figure this out.

    Thanks again

    *** Booting Zephyr OS build v2.6.[00:00:00.214,324] <inf> BH1749: BH1749 initialized
    0-rc1-ncs1  ***
    [00:00:00.250,915] <inf> asset_tracker: Asset tracker started
    [00:00:00.257,141] <inf> watchdog: Watchdog timeout installed. Timeout: 60000
    [00:00:00.264,739] <inf> watchdog: Watchdog started
    [00:00:00.277,191] <dbg> nrf_cloud_transport.allocate_and_copy_client_id: client_id = nrf-352656101079153
    [00:00:00.292,205] <dbg> nrf_cloud_transport.nct_settings_set: Settings key: p_sesh, size: 4
    [00:00:00.301,147] <dbg> nrf_cloud_transport.nct_settings_set: Read setting val: 1
    [00:00:00.313,568] <dbg> nrf_cloud_transport.nct_topics_populate: accepted_topic: nrf-352656101079153/shadow/get/accepted
    [00:00:00.325,012] <dbg> nrf_cloud_transport.nct_topics_populate: rejected_topic: $aws/things/nrf-352656101079153/shadow/get/rejected
    [00:00:00.337,615] <dbg> nrf_cloud_transport.nct_topics_populate: update_delta_topic: $aws/things/nrf-352656101079153/shadow/update/delta
    [00:00:00.350,646] <dbg> nrf_cloud_transport.nct_topics_populate: update_topic: $aws/things/nrf-352656101079153/shadow/update
    [00:00:00.362,518] <dbg> nrf_cloud_transport.nct_topics_populate: shadow_get_topic: $aws/things/nrf-352656101079153/shadow/get
    [00:00:00.374,725] <inf> asset_tracker: Connecting to LTE network.
    [00:00:00.381,347] <inf> asset_tracker: This may take several minutes.
    +CEREG: 2,"0C3D","02BF6B05",7,0,0,"11100000","11100000"
    [00:00:02.437,744] <err> os: ***** USAGE FAULT *****
    [00:00:02.443,359] <err> os:   Stack overflow (context area not valid)
    [00:00:02.450,622] <err> os: r0/a1:  0xfdcf20f5  r1/a2:  0x01741200  r2/a3:  0x00000008
    [00:00:02.459,381] <err> os: r3/a4:  0x000003e8 r12/ip:  0x0005029c r14/lr:  0x00000003
    [00:00:02.468,139] <err> os:  xpsr:  0x00000000
    [00:00:02.473,419] <err> os: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
    [00:00:02.483,917] <err> os: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
    [00:00:02.494,415] <err> os: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
    [00:00:02.504,913] <err> os: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
    [00:00:02.515,411] <err> os: fpscr:  0x0005029c
    [00:00:02.520,660] <err> os: Faulting instruction address (r15/pc): 0x00000004
    [00:00:02.528,625] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
    [00:00:02.536,590] <err> os: Current thread: 0x20016a68 (unknown)
    

  • Hello!

    Good to hear that the solution helped! It depends a bit on what thread is crashing, but I guess this main stack. If so you can use the CONFIG_MAIN_STACK_SIZE to adjust. If that's not the case you can check the Zephyr.map file in the build folder to find which thread 0x20016a68 corresponds to and then increase the stack size by using a fitting Kconfig option.

    Best regards,
    Carl Richard

Related