Hello, I am trying to debug strange behavior of malloc/free on STM32L151VCT6A (ARM,Cortex-M3,32k ram, 256k flash) with openocd and gdb. Gdb attaches to openocd fine, target can be halted, but I cannot get any backtrace, semms like information about mcu staus is not passed back to gdb.
TL;DR; skip to second paragraph of 'The problems' section below.
Some background:
My application needs fairly large (for embedded world) buffers in some
routines, keeping them as globals and reusing turned out to be
error-prone, so I decided to setup heap and use calloc/free to
allocate buffers as needed.
In order to do so I inserted heap start and end into bss section in
linker script as follows (part in the middle is mine):
(...)
/* Uninitialized data section */
. = ALIGN(4);
.bss :
{
/* This is used by the startup in order to initialize the .bss
secion */
_sbss = .; /* define a global symbol at bss start */
__bss_start__ = _sbss;
*(.bss)
*(.bss*)
*(COMMON)
/* Place heap in BSS - DK */
. = ALIGN(8);
_heap_start = .;
. = . + _Min_Heap_Size;
. = ALIGN(4);
_heap_end = .;
/* /DK */
. = ALIGN(4);
_ebss = .; /* define a global symbol at bss end */
__bss_end__ = _ebss;
} >RAM
(...)
and provided _sbrk_r implementation based on this:
http://www.embedded.com/electronics-blogs/industry-comment/4023922/Embedding-GNU-Newlib-Part-2
(Replaced memory allocated statically with my new heap section defined
with linker script)
I verified that _heap_start, _heap_end and _Min_Heap_Size have indeed
good values (Size is 0x1000, start points to some address after data
section and end is bigger by 0x1000).
The problems:
The first call to calloc (I'm requesting 512 byte buffer) causes
_sbrk_r call with argument 0x20000128 (Somehow ram origin got added to
incr arg?) and of course everything blows up. If I subtract 0x20000000
from _sbrk argument allocation seems to work, but CPU hardfaults
immediately after free is called.
I tried debugging this with gdb (arm-none-eabi version). GDB attaches
to openocd correctly, I can setup breakpoints, and program halts in
correct spot, but I cannot get any stack trace - it just prints
(gdb) bt
#0 0x08000ca0 in Reset_Handler ()
Monitor reset halt and run commands work perfectly fine.
Openocd log:
Open On-Chip Debugger 0.9.0 (2015-05-19-13:50)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
adapter speed: 300 kHz
adapter_nsrst_delay: 100
none separate
cortex_m reset_config sysresetreq
Info : clock speed 300 kHz
Info : SWD IDCODE 0x2ba01477
Info : stm32l1.cpu: hardware has 6 breakpoints, 4 watchpoints
adapter speed: 300 kHz
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000ca0 msp: 0x20007ffc
STM32L: Enabling HSI
adapter speed: 2000 kHz
** Programming Started **
auto erase enabled
Info : STM32L flash has dual banks. Bank (0) size is 192kb, base
address is 0x8000000 wrote 53248 bytes from file
build/MinSizeRel/firmware.elf in 2.902381s (17.916 KiB/s) **
Programming Finished ** ** Verify Started **
verified 52672 bytes in 0.396958s (129.579 KiB/s)
** Verified OK **
** Resetting Target **
Info : accepting 'gdb' connection on tcp/3333
Info : SWD IDCODE 0x2ba01477
Error: Failed to read memory at 0xfffff000
I launched gdb as follows:
arm-none-eabi-gdb build/MinSizeRel/firmware.elf
and then connected to openocd:
(gdb) target extended-remote localhost:3333
I suspect that it has something to do with failed memory read by openocd
(Maybe addresses read by gdb and passed to openocd somehow got messed
up)
Has somebody encountered similar issues with gdb/openocd
(or calloc/free/sbrk? - that's OT but )?
Debugging worked fine before (on another target - STM32F103),
maybe I'm just missing something stupid.
I don't know if this is directly related to openocd stuff, it might
just be problem with my setup or gdb, I just want to make sure.
Daniel
--
() ascii ribbon campaign - against html e-mail
/\ - against proprietary attachments
pgpSdCwJ_oc0q.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
