From: Paul F. <fer...@gm...> - 2014-10-05 10:27:23
|
Hi, On Sun, Oct 05, 2014 at 10:58:43AM +0100, Tobias Reithmaier wrote: > i have a problem with openocd when i debug the cortex-m3 processor LPC1788 with GDB. > When i single step through the startup code, which is from lpcxpresso-IDE called cr_startup178x.c > the jump to SystemInit and main fails. Try single-instruction stepping then to see what exactly happens. > loops where ignored. GDB just jumps over them. Sometimes optimisation artifacts are confusing, indeed. Look through disassembly and stepi through it. > With JLinkGDBServer it works. That's strange indeed. You can try to compare what happens on the GDB serial protocol layer by using "set debug remote 1" in gdb. > A second question: What is the best way to reset the target-cpu and jump to the reset isr with openocd? > monitor reset halt dont jump back to the reset vector. If you really want to break on the very beginning of the reset vector you have to use "reset_config trst_and_srst srst_nogates connect_assert_srst" (or srst_only), with srst actually connected to the target, and the target properly supporting ADIv5 with SRST asserting (stm32 works this way, I don't know about the others). Then "reset halt" is guaranteed to stop on the very first Reset_Vector instruction. > I append the openocd-output. It's hard to tell without seeing what you're doing during that. The usual procedure is to "load" from within GDB and then "mon reset halt" and stepi until you have your startup debugged or just "start" if you want to break at main(). HTH |