3
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ Is the processor running a valid program with all its trap handlers configured? \$\endgroup\$ – pjc50 Aug 27 '13 at 12:11
  • \$\begingroup\$ No event handlers have been declared. \$\endgroup\$ – Vorac Aug 27 '13 at 12:15
3
\$\begingroup\$

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

# Open openocd and pipe data throudh stdin/stdout.
# Openocd quits after gdb exits.
target remote | /usr/local/bin/openocd -f linux_config.cfg

openocd.cfg:

gdb_port pipe

And it magically worked.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.