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.
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:
warning:
Loadable section "RW_m_data" outside of ELF segments
warning:
Loadable section "RW_m_ncache" outside of ELF segments
done.
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 :
mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/device/TOOLCHAIN_ARM_STD/MIMXRT1052xxxxx.sct
linker specification file.
In case of GCC ARM it’s in the
mbed-os/targets/TARGET_NXP/TARGET_MCUXpresso_MCUS/TARGET_MIMXRT1050/device/TOOLCHAIN_GCC_ARM/MIMXRT1052xxxxx.ld
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 https://forums.mbed.com/t/static-library-and-mbed-app-json
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).
@hudakz
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
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:
warning:
Loadable section "RW_m_data" outside of ELF segments
warning:
Loadable section "RW_m_ncache" outside of ELF segments
done.
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: www.nxp.com
** mail: support@nxp.com
**
** ###################################################################
*/
#define __ram_vector_table__ 1
#if (defined(__ram_vector_table__))
#define __ram_vector_table_size__ 0x00000400
#else
#define __ram_vector_table_size__ 0x00000000
#endif
#if !defined(MBED_APP_START)
#define MBED_APP_START 0x60000000
#endif
#if !defined(MBED_APP_SIZE)
#define MBED_APP_SIZE 0x400000
#endif
#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
#else
#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
#endif
#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_CONF_TARGET_BOOT_STACK_SIZE)
# if defined(MBED_BOOT_STACK_SIZE)
# define MBED_CONF_TARGET_BOOT_STACK_SIZE MBED_BOOT_STACK_SIZE
# else
# define MBED_CONF_TARGET_BOOT_STACK_SIZE 0x400
# endif
#endif
#if (defined(__stack_size__))
#define Stack_Size __stack_size__
#else
#define Stack_Size MBED_CONF_TARGET_BOOT_STACK_SIZE
#endif
#if (defined(__heap_size__))
#define Heap_Size __heap_size__
#else
#define Heap_Size 0x0400
#endif
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)
}
#endif
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 {
}
#else
VECTOR_RAM m_interrupts_start EMPTY 0 {
}
#endif
RW_m_data m_data_start m_data_size { ; RW data
.ANY (+RW +ZI)
*(m_usb_dma_init_data)
*(m_usb_dma_noninit_data)
}
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?
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.
Thanks I really appreciate it.
Hello @JojoS . That’s certainly possible. I’ve some issues with pyOCD in the past.
Thank you,