[Resolution: user hardware problem]
First of all, congats on all the work and effort put in this project!
Got a SEGGER j-link (hardware version 8.0, IAR OEM) and installed the corresponding Eclipse plug-in.
The target uC is STM32F103RC.
I am able to flash the uC, run the firmware and make it stop at breakpoints. However, when a breakpoint (any breakpoint) is encountered, I get the following message in the debug window:
Thread #1
<main> (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)Strangely, the current address is reported as 0x0, and then I am unable to to step or to resume program execution (hence, I cannot use the debug feature).
Any hint on what is wrong is truly apreciated.
Setup:
Windows 8.1
C/C++ GDB Hardware Debugging 8.6.0.201502131403
Eclipse IDE for C/C++ Developers 4.4.2.20150219-0708
EPP CPP Feature 4.4.2.20150219-0708
GNU ARM C/C++ Cross Compiler 1.13.1.201504061754
GNU ARM C/C++ J-Link Debugging 3.2.1.201504061754
GNU ARM C/C++ OpenOCD Debugging 3.2.1.201504061754
GNU ARM C/C++ Packs (Experimental) 2.2.2.201504061754
GNU ARM C/C++ STM32Fx Project Templates 2.2.5.201504061754
It is hard to tell, either the project is wrong, or the environment was damaged.
did you create the project with the STM32F1 template? if not, can you create a simple blinky project and check the debugger behaviour?
Hi. Thank you for your hint. After asking for help I kept working on this and I came accross an unexpected result:
I am out I/O of pins in my microcontroller, so I chose SWD, since it saves me two pins. SWD mode (not JTAG) is sellected in the "Debugger" tab in my debug configuration.
It happens someone messed up with the pins, and remapped TCK and TMS pins as GPIO instead of TDI and TDO. So, flashing after a reset is possible, but SWD is obviously lost after software remapping.
So, this is not a gnu arm eclipse problem, it is an hardware design problem.
You can close this ticket now. Once again, thank you for your help and your fantastic work on gnu arm eclipse!
ok, glad you fixed it.
Diff: