Arm Mbed OS support forum

mBED Studio Debugger not displaying variable values correctly?

On an NXP RT1050 EVKB using CMSIS/DAP to debug a simple program, it appears that the debugger is having a hard time correctly displaying the value of an array of uint_8. I’ve attached an image of the debug session.

Unless I’m missing something it seems like Variables->Local displaying mac shouldn’t be showing the array as being filled with 0x00. And the gdb console even believes the values in the mac array are 0x00.

Am I doing something wrong or is this a bug in mbed studio?

Are these forums dead?
Not even a “Your an idiot for posting such a stupid question” reply?

Hello Jim,

Mbed build profiles are located in the mbed-os/tools/profiles directory. You can change Mbed’s default debug profile by modifying the debug.json file.

  • Mbed Studio ships with the Arm Compiler 6 and the default debug optimization level is "-O1". To get more debug info change it to "-O0" in the “ARMC6” section.

  • If you’d like to compile with GCC ARM then have a look at Switching to GCC - Installing | Mbed Studio Documentation. I that case change the optimization level from "-Og" to "O0" in the “GCC_ARM” section.

better than modifying the original mbed repo is to use a modified copy and to supply it by the --profile switch.
I have used this with the mbed-cli, hopefully its possible also with Mbed Studio.
There is also a pending PR for changing -O1 to -O0:

It looks like you are tracing the set_mac_address(), there was already a thread in this forum that it did not work with KL66F target. I have tried this also on a STM32, but it also did not work there. I have opened an issue for this and tried already to fix the problem, but the code is very obscure and no fun to trace.

Thank you for that information. I appreciate it much.

Thank you! I appreciate it.

@JojoS @hudakz

Thanks again. Now I’ve changed the optimization level as you both suggested. However, now when I debug the program I see that GDB complains while loading the code:

Loadable section "RW_m_data" outside of ELF segments
Loadable section "RW_m_ncache" outside of ELF segments

And when the program runs it doesn’t work as expected. It seems to get only part way through execution and then seems to do nothing.

Is this an indication that with -g O0 the code is too large to fit into memory?

My board is an NXP RT1050 EVKB which has 512KB internal RAM, 96KB ROM and external flash and RAM 512Mb Flash and 256Mb SDRAM.

My application is very small… it really only does some simple ethernet reads and writes to a website.

If you compile with the Arm Compiler 6 the memory configuration is defined in the :


linker specification file.
In case of GCC ARM it’s in the


Here you can find the location and size of these SRAM memories:

#define m_data_start                   0x80000000
#define m_data_size                    0x01E00000

#define m_ncache_start                 0x81E00000
#define m_ncache_size                  0x00200000

Is this an indication that with -g O0 the code is too large to fit into memory?

Even if your program (code) is small and fits into the flash memory it can use a large amount of SRAM. For example, if you define large buffers/arrays. So it’s indication that your code uses more SRAM than can fit into the SRAM rather than the code is too large to fit into the flash memory.

Thanks again.
My code uses a single 1k buffer.

It’s surprising that the linker doesn’t complain at link time about not having enough memory.

Shouldn’t it know if .text and .data will be too small?

I appreciate your help once again.

Is it possible in mBED studio to compile just the OS components with a different level of optimization and into a single linkable object so that my application code can be compiled with -g O0 and linked with the OS object file?

I don’t need full debug symbols for the OS components… Only my application code needs it.

You are absolutely right. The linker should warn you about that. A table showing memory usage is usually displayed at the the end of a successful compilation.

Is it possible in mBED studio to compile just the OS components with a different level of optimization and into a single linkable object so that my application code can be compiled with -g O0 and linked with the OS object file?

I’ve never done it but I think that’s possible:

  • A static mbed-os library (libmbed-os.a) shall be built using the mbed-cli command line interface (Mbed Studion doesn’t have such feature yet). In addition I’m not sure the Arm Compiler 6 is capable to build static libraries so I’d suggest to use the GCC ARM instead. This thread could help.

  • You can use a mbed_app.json configuration file to configure the mbed-os library to your needs. See

  • Create a new project with the Mbed Studio and delete the mbed-os directory (mbed-os source files) . Copy & paste the libmbed-os.a static library file into the root directory of the project and compile with the GCC ARM compiler (see the link in my first post how to switch Mbed Studio to GCC ARM).

1 Like

The table for the build with no optimization looks like this:

Elf2Bin: transact-sp2
| Module               |           .text |     .data |          .bss |
| [lib]\c_w.l          |     5694(+5694) |   16(+16) |     348(+348) |
| [lib]\fz_wv.l        |         26(+26) |     0(+0) |         0(+0) |
| [lib]\libcpp_w.l     |           1(+1) |     0(+0) |         0(+0) |
| [lib]\libcppabi_w.l  |         44(+44) |     0(+0) |         0(+0) |
| anon$$obj.o          |         48(+48) |     0(+0) |   2048(+2048) |
| main.o               |     2744(+2744) |     0(+0) |     460(+460) |
| mbed-os\cmsis        |   23401(+23401) | 168(+168) |   6609(+6609) |
| mbed-os\connectivity | 127033(+127033) | 299(+299) | 45535(+45535) |
| mbed-os\drivers      |     6935(+6935) |     0(+0) |         0(+0) |
| mbed-os\events       |     3126(+3126) |     0(+0) |   3104(+3104) |
| mbed-os\hal          |     3451(+3451) |     8(+8) |     115(+115) |
| mbed-os\platform     |   18971(+18971) |   64(+64) |   1104(+1104) |
| mbed-os\rtos         |     3021(+3021) |     0(+0) |         8(+8) |
| mbed-os\targets      |   35252(+35252) |   24(+24) |     442(+442) |
| Subtotals            | 229747(+229747) | 579(+579) | 59773(+59773) |
Total Static RAM memory (data + bss): 60352(+60352) bytes
Total Flash memory (text + data): 230326(+230326) bytes

58KB for RAM is needed

  • My board has a processor with 512KB SRAM/TCM internal memory. This SRAM can be shared with TCM and starts at address 0x00.
    So I have to figure out how mbed studio has configured this region of memory by looking at the .sct file which I’ll show below.

  • The board (NXP RT1050 EVKB) has external SDRAM of 256 Mb which is 32MB. So that is plenty of space for the 58KB RAM needed by the application.

~225KB for Flash is needed

  • The processor (NXP MX RT 1052) has 96 KB ROM starting at address 0x200000
  • The board has 64MB of HyperFlash. I can’t seem to tell where it is is the memory map.

So it seems to me that if the linker file is setting things up “properly” everything should fit. The .sct file is below if you want to have a look. You might see something I missed.

And the fact that linker isn’t complaining seems to indicate that it was able to fit everything into ROM/Flash/RAM.

The warning message only appear when GDB is loading the image:

Loadable section "RW_m_data" outside of ELF segments
Loadable section "RW_m_ncache" outside of ELF segments

I really appreciate you taking the time to help me out. I would be willing to send you some money or something for your time…

#! armclang -E --target=arm-arm-none-eabi -x c -mcpu=cortex-m7
** ###################################################################
**     Processors:          MIMXRT1052CVJ5B
**                          MIMXRT1052CVL5B
**                          MIMXRT1052DVJ6B
**                          MIMXRT1052DVL6B
**     Compiler:            Keil ARM C/C++ Compiler
**     Reference manual:    IMXRT1050RM Rev.1, 03/2018
**     Version:             rev. 1.0, 2018-09-21
**     Build:               b180921
**     Abstract:
**         Linker file for the Keil ARM C/C++ Compiler
**     Copyright 2016 Freescale Semiconductor, Inc.
**     Copyright 2016-2018 NXP
**     All rights reserved.
**     SPDX-License-Identifier: BSD-3-Clause
**     http:       
**     mail:       
** ###################################################################

#define __ram_vector_table__           1

#if (defined(__ram_vector_table__))
  #define __ram_vector_table_size__    0x00000400
  #define __ram_vector_table_size__    0x00000000

#if !defined(MBED_APP_START)
  #define MBED_APP_START 0x60000000

#if !defined(MBED_APP_SIZE)
  #define MBED_APP_SIZE 0x400000

#if !defined(MBED_APP_COMPILE)
#define m_flash_config_start           MBED_APP_START
#define m_flash_config_size            0x00001000

#define m_ivt_start                    MBED_APP_START + 0x1000
#define m_ivt_size                     0x00001000

#define m_interrupts_start             MBED_APP_START + 0x2000
#define m_interrupts_size              0x00000400

#define m_text_start                   MBED_APP_START + 0x2400
#define m_text_size                    MBED_APP_SIZE - 0x2400
#define m_interrupts_start             MBED_APP_START
#define m_interrupts_size              0x00000400

#define m_text_start                   MBED_APP_START + 0x400
#define m_text_size                    MBED_APP_SIZE - 0x400

#define m_text2_start                  0x00000000
#define m_text2_size                   0x00020000

#define m_data_start                   0x80000000
#define m_data_size                    0x01E00000

#define m_ncache_start                 0x81E00000
#define m_ncache_size                  0x00200000

#define m_interrupts_ram_start         0x20000000
#define m_interrupts_ram_size          __ram_vector_table_size__

#define m_data2_start                   (m_interrupts_ram_start + m_interrupts_ram_size)
#define m_data2_size                    (0x00020000 - m_interrupts_ram_size)

#define m_data3_start                  0x20200000
#define m_data3_size                   0x00040000

/* Sizes */

#  if defined(MBED_BOOT_STACK_SIZE)
#  else
#  endif

#if (defined(__stack_size__))
  #define Stack_Size                   __stack_size__
  #define Stack_Size                   MBED_CONF_TARGET_BOOT_STACK_SIZE

#if (defined(__heap_size__))
  #define Heap_Size                    __heap_size__
  #define Heap_Size                    0x0400

LR_IROM1 MBED_APP_START m_text_start+m_text_size-MBED_APP_START {   ; load region size_region
#if !defined(MBED_APP_COMPILE)
  RW_m_config_text m_flash_config_start FIXED m_flash_config_size { ; load address = execution address
    * (.boot_hdr.conf, +FIRST)

  RW_m_ivt_text m_ivt_start FIXED m_ivt_size { ; load address = execution address
    * (.boot_hdr.ivt, +FIRST)
    * (.boot_hdr.boot_data)
    * (.boot_hdr.dcd_data)
  VECTOR_ROM m_interrupts_start FIXED m_interrupts_size { ; load address = execution address
    * (RESET,+FIRST)
  ER_IROM1 m_text_start FIXED m_text_size { ; load address = execution address
    * (InRoot$$Sections)
    .ANY (+RO)

#if (defined(__ram_vector_table__))
  VECTOR_RAM m_interrupts_ram_start EMPTY m_interrupts_ram_size {
  VECTOR_RAM m_interrupts_start EMPTY 0 {
  RW_m_data m_data_start m_data_size { ; RW data
    .ANY (+RW +ZI)
  RW_IRAM1 ImageLimit(RW_m_data)  {
  ARM_LIB_HEAP AlignExpr(+0, 16) EMPTY (m_data_start + m_data_size - Stack_Size - AlignExpr(ImageLimit(RW_IRAM1), 16)) {
  ARM_LIB_STACK m_data_start+m_data_size EMPTY -Stack_Size  { ; Stack region growing down
  RW_m_ram_text m_text2_start m_text2_size {
    * (CodeQuickAccess)
  RW_m_ncache m_ncache_start m_ncache_size { ; ncache RW data
    * (NonCacheable.init)
    * (*NonCacheable)

maybe its a problem with gdb/pyOCD?

1 Like

The 512KB SRAM/TCM memory is not set up and used by the linker file so Mbed doesn’t know about it! The largest portion of contiguous SRAM configures by the linker file has 0x01E00000 bytes (about 30 kBytes).

Which micro-controller is installed on the board (could you give us a link to the datasheet) ?

Hello, it’s an NXP i.MX RT1052 on an i.MX NXP RT1050 EVKB eval board.
RT1052 Processor Data Sheet
NXP i.MX RT1050 EVKB Eval Board

But even if the linker doesn’t know about the processor internal memory, the board has 32MB of external SDRAM which I believe starts at 0x80000000 with a total memory space of 1.5GB

And the map file seems to indicate it is using external SDRAM: ( this is for a release build so no debug symbols )

0x8000defc   0x000000bc   Zero   RW           15    .bss.redThread      BUILD/MIMXRT1050_EVK/ARMC6/main.o
    0x8000dfb8   0x00000040   Zero   RW         3435    .bss.rx_buff        BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/connectivity/drivers/emac/TARGET_NXP_EMAC/TARGET_IMX/imx_emac.o
    0x8000dff8   0x00000040   Zero   RW         3436    .bss.rx_ptr         BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/connectivity/drivers/emac/TARGET_NXP_EMAC/TARGET_IMX/imx_emac.o
    0x8000e038   0x00000080   Zero   RW        30221    .bss.s_EDMAHandle   BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/drivers/fsl_edma.o
    0x8000e0b8   0x00000004   Zero   RW        30345    .bss.s_ENETHandle   BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/drivers/fsl_enet.o
    0x8000e0bc   0x0000000c   Zero   RW        30446    .bss.s_flexcanHandle  BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/drivers/fsl_flexcan.o
    0x8000e0c8   0x00000004   Zero   RW        31007    .bss.s_flexspiHandle  BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/drivers/fsl_flexspi.o
    0x8000e0cc   0x00000014   Zero   RW        31260    .bss.s_lpspiHandle  BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/drivers/fsl_lpspi.o
    0x8000e0e0   0x00000024   Zero   RW        31395    .bss.s_lpuartHandle  BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/drivers/fsl_lpuart.o
    0x8000e104   0x00000020   Zero   RW        31776    .bss.s_saiHandle    BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/drivers/fsl_sai.o
    0x8000e124   0x0000000c   Zero   RW        32211    .bss.s_usdhcHandle  BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/drivers/fsl_usdhc.o
    0x8000e130   0x00000004   Zero   RW          694    .bss.singleton_mutex_id  BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/cmsis/device/rtos/source/mbed_rtos_rtx.o
    0x8000e134   0x0000001c   Zero   RW          692    .bss.singleton_mutex_obj  BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/cmsis/device/rtos/source/mbed_rtos_rtx.o
    0x8000e150   0x00000001   Zero   RW         6397    .bss.tcp_timer      BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/connectivity/lwipstack/lwip/src/core/lwip_tcp.o
    0x8000e151   0x00000003   PAD
    0x8000e154   0x00000048   Zero   RW         5811    .bss.tcpip_mbox     BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/connectivity/lwipstack/lwip/src/api/lwip_tcpip.o
    0x8000e19c   0x00000001   Zero   RW         6513    .bss.tcpip_tcp_timer_active  BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/connectivity/lwipstack/lwip/src/core/lwip_timeouts.o
    0x8000e19d   0x00000003   PAD
    0x8000e1a0   0x00000004   Zero   RW          707    .bss.terminate_hook  BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/cmsis/device/rtos/source/mbed_rtx_handlers.o
    0x8000e1a4   0x00000288   Zero   RW         5589    .bss.thread_pool    BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/connectivity/lwipstack/lwip-sys/arch/lwip_sys_arch.o
    0x8000e42c   0x00000004   Zero   RW         5588    .bss.thread_pool_index  BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/connectivity/lwipstack/lwip-sys/arch/lwip_sys_arch.o
    0x8000e430   0x00000004   Zero   RW         6548    .bss.udp_pcbs       BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/connectivity/lwipstack/lwip/src/core/lwip_udp.o
    0x8000e434   0x00000001   Zero   RW        29474    .bss.us_ticker_inited  BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_IMX/us_ticker.o

    Execution Region RW_IRAM1 (Base: 0x8000e438, Size: 0x00000000, Max: 0xffffffff, ABSOLUTE)

    **** No section assigned to this execution region ****

    Execution Region ARM_LIB_HEAP (Base: 0x8000e440, Size: 0x01df17c0, Max: 0x01df17c0, ABSOLUTE)

    Base Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x8000e440   0x01df17c0   Zero   RW            2    ARM_LIB_HEAP.bss    anon$$obj.o

    Execution Region ARM_LIB_STACK (Base: 0x81dffc00, Size: 0x00000400, Max: 0x00000400, ABSOLUTE)

    Base Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x81dffc00   0x00000400   Zero   RW            3    ARM_LIB_STACK.bss   anon$$obj.o

    Execution Region RW_m_ncache (Base: 0x81e00000, Size: 0x000000c4, Max: 0x00200000, ABSOLUTE)

    Base Addr    Size         Type   Attr      Idx    E Section Name        Object

    0x81e00000   0x000000c0   Data   RW         3438    NonCacheable        BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/connectivity/drivers/emac/TARGET_NXP_EMAC/TARGET_IMX/imx_emac.o
    0x81e000c0   0x00000004   Data   RW        32210    NonCacheable        BUILD/MIMXRT1050_EVK/ARMC6/mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/drivers/fsl_usdhc.o

Thanks again!

Unfortunately, access to the datasheet and the other link was denied. However, according to the map file you provided there seems to be a quite large heap section ( 0x01df17c0 bytes = about 30 000 kBytes!). To utilize it try to create as much dynamic objects and arrays as possible by using the new operator. For example

int *buf = new int(n);  // array created on the heap

rather than

int buf[n];  // array created on the static memory section or on the stack

I will do that. However, I’m only using a 1024 byte array and a 256 byte array. Seems like that wouldn’t be the problem?

If you want, please try the datasheet links again. They should be available to you now.

Thanks again!

Now they work OK. I’ll take a look tomorrow.

1 Like

Thanks I really appreciate it.

Hello @JojoS . That’s certainly possible. I’ve some issues with pyOCD in the past.

Thank you,

@hudakz @JojoS

Should I create a new thread now that the problem has changed?