If enabling of global software reset is handled in reset-assert-pre
stage, target would get into Thumb state occasionally.
That's, the target is not indeed reset.
Fix this by moving PRM_RSTCTRL in the reset-start stage
like previous config.
Signed-off-by: Matt Hsu <m...@0xlab.org>
---
tcl/target/omap3530.cfg | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tcl/target/omap3530.cfg b/tcl/target/omap3530.cfg
index 45f3c01..ee8fa37 100644
--- a/tcl/target/omap3530.cfg
+++ b/tcl/target/omap3530.cfg
@@ -60,12 +60,12 @@ proc omap3_dbginit {target} {
# 16.8MHz/2 = 8.4MHz core clock, even before a bootloader kicks in.
# OK to speed up *after* PLL and clock tree setup.
jtag_rclk 1000
-$_TARGETNAME configure -event "reset-start" { jtag_rclk 1000 }
+$_TARGETNAME configure -event "reset-init" { jtag_rclk 1000 }
# REVISIT This assumes that SRST is unavailable, so we must assert reset
# ourselves using PRM_RSTCTRL. RST_GS (2) is a warm reset, like ICEpick
# would issue. RST_DPLL3 (4) is a cold reset.
set PRM_RSTCTRL 0x48307250
-$_TARGETNAME configure -event reset-assert-pre "$_TARGETNAME mww $PRM_RSTCTRL
2"
+$_TARGETNAME configure -event reset-start "$_TARGETNAME mww $PRM_RSTCTRL 2"
$_TARGETNAME configure -event reset-assert-post "omap3_dbginit $_TARGETNAME"
--
1.6.0.4
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
