Here is what the documentation has to say:
— Command: reset
— Command: reset run
— Command: reset halt
— Command: reset init
Perform as hard a reset as possible, using SRST if possible. All defined
targets will be reset, and target events will fire during the reset sequence.
The optional parameter specifies what should happen after the reset. If there is
no parameter, a reset run is executed. The other options will not work on all
systems. See Reset Configuration.
run Let the target run
halt Immediately halt the target
init Immediately halt the target, and execute the reset-init script
From OpenOCD Commands
I open OpenOCD, then in another terminal I run arm-none-eabi-gdb end execute monitor reset halt in order to tell the target to reset and halt the processor, in order to later setup braekpoints and run.
However, the responce from the processor is often different:
(gdb) monitor reset halt
JTAG tap: sam7x512.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target state: halted
target halted in ARM state due to debug-request, current mode: FIQ
cpsr: 0x600000d1 pc: 0x00000050
NOTE! DCC downloads have not been enabled, defaulting to slow memory writes. Type 'help dcc'.
NOTE! Severe performance degradation without fast memory access enabled. Type 'help fast'.
Other times, it goes this way:
target state: halted
target halted in ARM state due to debug-request, current mode: Abort
cpsr: 0x600000d7 pc: 0x00000044
Yet another times (within the same run, I just opened gdb and run monitor reset halt a bunch of times):
target state: halted
target halted in ARM state due to debug-request, current mode: Undefined instruction
cpsr: 0x600000db pc: 0x00000038
What are those states?
Best Answer
I worked around my problem. Still very interested to learn about those states, though!
I botched the connection through port 3333, and used openocd's piping capabilities:
.gdbinit
openocd.cfg:
And it magically worked.