raspberrypi/openocd

question about monitor reset init operation for raspberrypi pico

victoryred opened this issue · 2 comments

Is there a reset-init script for the rp2040 microcontroller in the pico? This is in the Openocd documentation...

Terminal 1
openocd -s /home/penta/.arduino15/packages/rp2040/hardware/rp2040/3.6.2/lib/ -f picoprobe_cmsis_dap.tcl

Terminal 2
gdb-multiarch /tmp/arduino/sketches/8CF8FC96861539E476DC0E8FD09DD06D/sha1.ino.elf
target remote localhost:3333

/*
(gdb) monitor reset init
[rp2040.core0] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
[rp2040.core1] halted due to debug-request, current mode: Thread
xPSR: 0xf1000000 pc: 0x000000ea msp: 0x20041f00
(gdb)

However;
(gdb) monitor reset
(gdb) monitor init // Equiv. works without halting
(gdb)

*/

Does Raspberrypi have the reset-init script? If not where can I find it? When I'm running manually in a terminal I have control over what I type, in the Arduino-ide 2.2.1 or VSCode not so much.

9.1 Types of Reset

There are many kinds of reset possible through JTAG, but they may not all work with a given board and adapter. That’s part of why reset configuration can be error prone.

System Reset ... the SRST hardware signal resets all chips connected to the JTAG adapter, such as processors, power management chips, and I/O controllers. Normally resets triggered with this signal behave exactly like pressing a RESET button.
JTAG TAP Reset ... the TRST hardware signal resets just the TAP controllers connected to the JTAG adapter. Such resets should not be visible to the rest of the system; resetting a device’s TAP controller just puts that controller into a known state.
Emulation Reset ... many devices can be reset through JTAG commands. These resets are often distinguishable from system resets, either explicitly (a "reset reason" register says so) or implicitly (not all parts of the chip get reset).
Other Resets ... system-on-chip devices often support several other types of reset. You may need to arrange that a watchdog timer stops while debugging, preventing a watchdog reset. There may be individual module resets. 

In the best case, OpenOCD can hold SRST, then reset the TAPs via TRST and send commands through JTAG to halt the CPU at the reset vector before the 1st instruction is executed. Then when it finally releases the SRST signal, the system is halted under debugger control before any code has executed. This is the behavior required to support the reset halt and reset init commands; after reset init a board-specific script might do things like setting up DRAM. (See Reset Command.)

This IS the Reset doc...
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 

Regards-

I found this in openocd/scripts/test/syntax1.cfg-

$_TARGETNAME configure -event reset-init {
soft_reset_halt
mvb 0xE01FC040 0x01
}

The Arduino-ide v2.2.1 throws the following notification after halting as stated above-

"Request 2 cancelled on connection close"