tcl/target/gd32vf103: work around broken ndmreset
On this chip, the ndmreset bit in the RISC-V debug module doesn't trigger a system reset like it should. To work around this, add a custom "reset-assert" handler in its config file that resets the system by writing to memory-mapped registers. I've tested this workaround on a Sipeed Longan Nano dev board with a GD32VF103CBT6 chip. It works correctly for both "reset run" and "reset halt" (halting at pc=0 for the latter). I originally submitted[1] this workaround to the riscv-openocd fork of OpenOCD. That fork's maintainers accepted it, but have not upstreamed it like they have several other of my changes. [1] https://github.com/riscv/riscv-openocd/pull/538 Change-Id: I7482990755b300fcbe4963c9a599d599bc02684d Signed-off-by: Thomas Hebb <tommyhebb@gmail.com> Signed-off-by: Tomas Vanek <vanekt@fbl.cz> Reviewed-on: https://review.openocd.org/c/openocd/+/6957 Tested-by: jenkins Reviewed-by: zapb <dev@zapb.de>
This commit is contained in:
parent
1b0b07baab
commit
7ac389cf47
|
@ -28,6 +28,12 @@ jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x1000563d
|
|||
set _TARGETNAME $_CHIPNAME.cpu
|
||||
target create $_TARGETNAME riscv -chain-position $_TARGETNAME
|
||||
|
||||
proc default_mem_access {} {
|
||||
riscv set_mem_access progbuf
|
||||
}
|
||||
|
||||
default_mem_access
|
||||
|
||||
$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0
|
||||
|
||||
set _FLASHNAME $_CHIPNAME.flash
|
||||
|
@ -40,3 +46,74 @@ $_TARGETNAME configure -event reset-init {
|
|||
# DBGMCU_CR |= DBG_WWDG_STOP | DBG_IWDG_STOP
|
||||
mmw 0xE0042004 0x00000300 0
|
||||
}
|
||||
|
||||
# On this chip, ndmreset (the debug module bit that triggers a software reset)
|
||||
# doesn't work. So for JTAG connections without an SRST, we need to trigger a
|
||||
# reset manually. This is an undocumented reset sequence that's used by the
|
||||
# JTAG flashing script in the vendor-supplied GD32VF103 PlatformIO plugin:
|
||||
#
|
||||
# https://github.com/sipeed/platform-gd32v/commit/f9cbb44819bc05dd2010cc815c32be0486800cc2
|
||||
#
|
||||
$_TARGETNAME configure -event reset-assert {
|
||||
set dmcontrol 0x10
|
||||
set dmcontrol_dmactive [expr {1 << 0}]
|
||||
set dmcontrol_ackhavereset [expr {1 << 28}]
|
||||
set dmcontrol_haltreq [expr {1 << 31}]
|
||||
|
||||
global _RESETMODE
|
||||
|
||||
# If hardware NRST signal is connected and configured (reset_config srst_only)
|
||||
# the device has been recently reset in 'jtag arp_init-reset', therefore
|
||||
# DM_DMSTATUS_ANYHAVERESET reads 1.
|
||||
# The following 'halt' command checks this status bit
|
||||
# and shows 'Hart 0 unexpectedly reset!' if set.
|
||||
# Prevent this message by sending an acknowledge first.
|
||||
set val [expr {$dmcontrol_dmactive | $dmcontrol_ackhavereset}]
|
||||
riscv dmi_write $dmcontrol $val
|
||||
|
||||
# Halt the core so that we can write to memory. We do this first so
|
||||
# that it doesn't clobber our dmcontrol configuration.
|
||||
halt
|
||||
|
||||
# Set haltreq appropriately for the type of reset we're doing. This
|
||||
# replicates what the generic RISC-V reset_assert() function would
|
||||
# do if we weren't overriding it. The $_RESETMODE hack sucks, but
|
||||
# it's the least invasive way to determine whether we need to halt.
|
||||
#
|
||||
# If we didn't override the generic handler, we'd actually still have
|
||||
# to do this: the default handler sets ndmreset, which prevents memory
|
||||
# access even though it doesn't actually trigger a reset on this chip.
|
||||
# So we'd need to unset it here, which involves a write to dmcontrol,
|
||||
# Since haltreq is write-only and there's no way to leave it unchanged,
|
||||
# we'd have to figure out its proper value anyway.
|
||||
set val $dmcontrol_dmactive
|
||||
if {$_RESETMODE ne "run"} {
|
||||
set val [expr {$val | $dmcontrol_haltreq}]
|
||||
}
|
||||
riscv dmi_write $dmcontrol $val
|
||||
|
||||
# Unlock 0xe0042008 so that the next write triggers a reset
|
||||
mww 0xe004200c 0x4b5a6978
|
||||
|
||||
# We need to trigger the reset using abstract memory access, since
|
||||
# progbuf access tries to read a status code out of a core register
|
||||
# after the write happens, which fails when the core is in reset.
|
||||
riscv set_mem_access abstract
|
||||
|
||||
# Go!
|
||||
mww 0xe0042008 0x1
|
||||
|
||||
# Put the memory access mode back to what it was.
|
||||
default_mem_access
|
||||
}
|
||||
|
||||
# Capture the mode of a given reset so that we can use it later in the
|
||||
# reset-assert handler.
|
||||
proc init_reset { mode } {
|
||||
global _RESETMODE
|
||||
set _RESETMODE $mode
|
||||
|
||||
if {[using_jtag]} {
|
||||
jtag arp_init-reset
|
||||
}
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue