jtag arp_init-reset works but reset halt does not

[D0ot]

Having a problem about reset on K210 using FT4232H as an adapter.

The command jtag arp_init-reset works but reset halt does not work. I am just wondering where the problem is?

openocd config file:

interface ftdi
ftdi_vid_pid 0x0403 0x6011

ftdi_channel 0

# Initial state and direction setting (ref. AN_135_MPSSE_Basics.pdf)
# ftdi_layout_init [data] [direction]

#  name   signal  state      direction  JTAG name
# *DBUS0  TCK/SK  (low =0)   (out=1)    TCK
# *DBUS1  TDI/DO  (low =0)   (out=1)    TDI
# *DBUS2  TDO/DI  (low =0)   (in =0)    TDO
# *DBUS3  TMS/CS  (high=1)   (out=1)    TMS
# *DBUS4  GPIOL0  (high=1)   (out=1)    (nSRST)
# *DBUS5  GPIOL1  (high=1)   (out=1)    (nTRST)
# *DBUS6  GPIOL2  (low =0)   (out=0)
# *DBUS7  GPIOL3  (low =0)   (out=0)    


ftdi_layout_init 0x38 0x3b

ftdi_layout_signal nSRST -data 0x10 -oe 0x10
ftdi_layout_signal nTRST -data 0x20 -oe 0x20
transport select jtag
adapter_khz 1000
gdb_port 3333

set _CHIPNAME riscv

jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x04e4796b

set _TARGETNAME $_CHIPNAME.cpu

target create $_TARGETNAME riscv -chain-position $_TARGETNAME

reset_config trst_and_srst 

init
halt

---

Using 'reset halt'

'rest halt' gdb output:

(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x000000008000a81a in ?? ()
(gdb) monitor reset halt
JTAG scan chain interrogation failed: all ones
Check JTAG interface, timings, target power, etc.
Trying to use configured scan chain anyway...
riscv.cpu: IR capture error; saw 0x1f not 0x01
Bypassing JTAG setup events due to errors
(gdb) 

after i type the lines above, the openocd got stuck.

'reset halt' openocd output:

Kendryte Open On-Chip Debugger For RISC-V v0.2.3 (2019-02-21)
Licensed under GNU GPL v2
adapter speed: 1000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : clock speed 1000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x04e4796b (mfg: 0x4b5 (<unknown>), part: 0x4e47, ver: 0x0)
Core [0] halted at 0x8000b5ea due to debug interrupt
Info : Examined RISCV core; found 2 harts
Info : Listening on port 3333 for gdb connections
Core [1] halted at 0x8000bf90 due to debug interrupt
Core [0] halted at 0x8000a81a due to debug interrupt
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : accepting 'gdb' connection on tcp/3333
Info : dropped 'gdb' connection
Info : accepting 'gdb' connection on tcp/3333
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: riscv.cpu: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Retrying memory read starting from 0x8000a81a with more delays
Info : Retrying memory read starting from 0x8000a81a with more delays
Info : Retrying memory read starting from 0x8000a81a with more delays
Info : Retrying memory read starting from 0x8000a81a with more delays
Info : Retrying memory read starting from 0x8000a81a with more delays
Info : Retrying memory read starting from 0x8000a81a with more delays
Info : Retrying memory read starting from 0x8000a81a with more delays
Info : Retrying memory read starting from 0x8000a81a with more delays
Info : Retrying memory read starting from 0x8000a81a with more delays
Info : Retrying memory read starting from 0x8000a81a with more delays
Info : Retrying memory read starting from 0x8000a81a with more delays
Info : Retrying memory read starting from 0x8000a81a with more delays
Info : Retrying memory read starting from 0x8000a81a with more delays

---

using jtag arp_init-reset

gdb output:

Type "apropos word" to search for commands related to "word".
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x000000008000b1c6 in ?? ()
(gdb) monitor jtag_init-reset
invalid command name "jtag_init-reset"
(gdb) monitor jtag arp_init-reset
JTAG scan chain interrogation failed: all ones
Check JTAG interface, timings, target power, etc.
Trying to use configured scan chain anyway...
Bypassing JTAG setup events due to errors

it looks wired...

openocd output:

Kendryte Open On-Chip Debugger For RISC-V v0.2.3 (2019-02-21)
Licensed under GNU GPL v2
adapter speed: 1000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : clock speed 1000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x04e4796b (mfg: 0x4b5 (<unknown>), part: 0x4e47, ver: 0x0)
Core [0] halted at 0x8000b606 due to debug interrupt
Info : Examined RISCV core; found 2 harts
Info : Listening on port 3333 for gdb connections
Core [1] halted at 0x8000bf90 due to debug interrupt
Core [0] halted at 0x8000b1c6 due to debug interrupt
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
dInfo : accepting 'gdb' connection on tcp/3333
invalid command name "jtag_init-reset"
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors

The device reseted but was not halted. it was running.

---

Is there any way to use a normal reset command ?

thanks !

[D0ot]

i checked the documentation of openocd finding this on Chapter 9

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], page 122.)

so my question is : is it possible to halt the cpu of k210 at the reset ?

[D0ot]

It seems that writing 1 to ndreset field in DCSR takes no effect... is it a hardware bug?