#122 blinky example does not reach main() w/STM32F100
[Resolution: Damaged Eclipse, after reinstall it worked]
Hello,
I am having difficulty debugging the sample blinky program using a STM32FEval board w/embedded STLINK/2 and OpenOCD. Basically the programs gets as far as SystemInit() but when that returns the program is lost. The program never makes it to main().
Summary of what I have done:
1. Created a new C++ project as per website
-
Updated packages and assigned the device in the project Properties
-
Verified the ROM and RAM address and sizes
-
After unsuccessful debug sessions to main(), set a breakpoint at _start(). Able to debug down into SystemInit() but when the function returns the debugger is lost.
-
Attempted to debug using the GDB HW debugger. The debug sessions terminates with the following messages:
Debug: 1383 333591 gdb_server.c:2526 gdb_v_packet(): wrote 7952 bytes from vFlash image to flash
Debug: 1384 333595 gdb_server.c:2662 gdb_input_inner(): received packet: 'P29=ffffffff'
Debug: 1385 333595 gdb_server.c:1285 gdb_set_register_packet(): -
Error: 1386 333595 gdb_server.c:1293 gdb_set_register_packet(): gdb requested a non-existing register
Debug: 1387 333595 gdb_server.c:1012 gdb_connection_closed(): GDB Close, Target: stm32f1x.cpu, state: halted, gdb_actual_connections=0 -
The above source code was using a toolchain built from source provide by GNU ARM Embedded. Installed another toolchain using the Debian package manager from GNU ARM. (these were the same GCC versions)
-
Created a new blinky project using the new toolchain.
-
Debug sessions produced the same results. The OpenOCD debug session output is:
GNU ARM Eclipse 64-bit Open On-Chip Debugger 0.8.0-00063-gbda7f5c (2015-01-31-18:50)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Started by GNU ARM Eclipse
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.237870
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 3333
Info : device id = 0x10006428
Warn : STM32 flash size failed, probe inaccurate - assuming 128k flash
Info : flash size = 128kbytes
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000220 msp: 0x20008000
semihosting is enabled
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000220 msp: 0x20008000, semihosting
Info : Padding image section 0 with 1 bytes
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0x20008000, semihosting
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000220 msp: 0x20008000, semihosting
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000220 msp: 0x20008000, semihosting
===== arm v7m registers
(0) r0 (/32): 0x08201D54
(1) r1 (/32): 0xFFFFFFF9
(2) r2 (/32): 0x08000241
(3) r3 (/32): 0x2000815C
(4) r4 (/32): 0xE000ED38
(5) r5 (/32): 0xE000ED34
(6) r6 (/32): 0x01010000
(7) r7 (/32): 0x20007FC8
(8) r8 (/32): 0xFFFFFFF9
(9) r9 (/32): 0x08001E54
(10) r10 (/32): 0xEF49435E
(11) r11 (/32): 0xC7DFB0D9
(12) r12 (/32): 0x75662087
(13) sp (/32): 0x20008000
(14) lr (/32): 0xFFFFFFFF
(15) pc (/32): 0x08000220
(16) xPSR (/32): 0x01000000
(17) msp (/32): 0x20008000
(18) psp (/32): 0x5C0985C8
(19) primask (/1): 0x00
(20) basepri (/8): 0x00
(21) faultmask (/1): 0x00
(22) control (/2): 0x00
===== Cortex-M DWT registers
(23) dwt_ctrl (/32)
(24) dwt_cyccnt (/32)
(25) dwt_0_comp (/32)
(26) dwt_0_mask (/4)
(27) dwt_0_function (/32)
(28) dwt_1_comp (/32)
(29) dwt_1_mask (/4)
(30) dwt_1_function (/32)
(31) dwt_2_comp (/32)
(32) dwt_2_mask (/4)
(33) dwt_2_function (/32)
(34) dwt_3_comp (/32)
(35) dwt_3_mask (/4)
(36) dwt_3_function (/32)
Info : halted: PC: 0x080006d8
Info : halted: PC: 0x080008a8
my first guess would be the memory map (please double check), then the openocd script, maybe you did not choose the right one.
I'm not sure I can test it, I have only a stm32f0discovery, does it match your board?
what openocd script did you use?
Thank you for responding!
I modified stm32100b_eval.cfg as follows. The main difference is the workspace area. I just noticed that it says 8K here but it is actually 32K on the STM32F100Z part. This was originally modified because it did not communicate with the embedded STLink/2 JTAG.
Last edit: Liviu Ionescu (ilg) 2015-03-13
Hello Again,
I have attached the evaluation board User Manual for your reference.
Great News!
I installed the "updates-test" packages and it makes it all the way to main!
One other difference: When I created the project I changed the processor to the "low density, value line" CPU type. The default is a "medium density" part. Also specified 512K for the flash vs. 128K. Do you think that could make a difference? I pick the exact part is "Settings/Device" after the project is built.
Where can you view the settings used when creating the project?
what settings?
the wizard inputs are all the configurable settings.
the memory size in the linker script must match exactly the processor.
currently this setting is used only to help the debugger display the peripheral registers, and does not influence the build.
btw, if you're doing just an evaluation, openocd may be enough, but if you plan serious development, go for the j-link.
FYI: I re-installed the original GNU ARM Eclipse plug-ins and everything works when you specify the exact RAM and ROM sizes. :^)
great!
in the future version of the wizard, after selecting the processor, the memory sizes will be filled in automatically, but for now, they must be set by hand.
Diff: