LM3S OpenOCD configuration from Jose Pablo Carballo

git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@5544 42af7a65-404d-4744-a932-0658087f49c3

3 files changed, 263 insertions, 0 deletions

diff --git a/nuttx/configs/lm3s6965-ek/README.txt b/nuttx/configs/lm3s6965-ek/README.txt
index 77f034bf5..94cf4d902 100644
--- a/nuttx/configs/lm3s6965-ek/README.txt
+++ b/nuttx/configs/lm3s6965-ek/README.txt
@@ -15,6 +15,7 @@ Contents
   NXFLAT Toolchain
   USB Device Controller Functions
   OLED
+  Using OpenOCD and GDB with an FT2232 JTAG emulator
   Stellaris LM3S6965 Evaluation Kit Configuration Options
   Configurations
 
@@ -103,6 +104,85 @@ OLED
   display.  Some tweaks to drivers/lcd/p14201.c would be required to support that
   LCD.
 
+Using OpenOCD and GDB with an FT2232 JTAG emulator
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+  Building OpenOCD under Cygwin:
+
+    Refer to configs/olimex-lpc1766stk/README.txt
+
+  Installing OpenOCD in Linux:
+
+    sudo apt-get install openocd
+
+  Helper Scripts.
+
+    I have been using the on-board FT2232 JTAG/SWD/SWO interface.  OpenOCD
+    requires a configuration file.  I keep the one I used last here:
+    
+      configs/lm3s6965-ek/tools/lm3s6965-ek.cfg
+
+    However, the "correct" configuration script to use with OpenOCD may
+    change as the features of OpenOCD evolve.  So you should at least
+    compare that lm3s6965-ek.cfg file with configuration files in
+    /usr/share/openocd/scripts.  As of this writing, the configuration
+    files of interest were:
+
+      /usr/share/openocd/scripts/interface/luminary.cfg
+      /usr/share/openocd/scripts/board/ek-lm3s6965.cfg
+      /usr/share/openocd/scripts/target/stellaris.cfg
+
+    There is also a script on the tools/ directory that I use to start
+    the OpenOCD daemon on my system called oocd.sh.  That script will
+    probably require some modifications to work in another environment:
+  
+    - Possibly the value of OPENOCD_PATH and TARGET_PATH
+    - It assumes that the correct script to use is the one at
+      configs/lm3s6965-ek/tools/lm3s6965-ek.cfg
+
+  Starting OpenOCD
+
+    Then you should be able to start the OpenOCD daemon like:
+
+      configs/lm3s6965-ek/tools/oocd.sh $PWD
+
+  Connecting GDB
+
+    Once the OpenOCD daemon has been started, you can connect to it via
+    GDB using the following GDB command:
+
+      arm-nuttx-elf-gdb
+      (gdb) target remote localhost:3333
+
+    NOTE:  The name of your GDB program may differ.  For example, with the
+    CodeSourcery toolchain, the ARM GDB would be called arm-none-eabi-gdb.
+
+    After starting GDB, you can load the NuttX ELF file:
+
+      (gdb) symbol-file nuttx
+      (gdb) monitor reset
+      (gdb) monitor halt
+      (gdb) load nuttx
+
+    NOTES:
+    1. Loading the symbol-file is only useful if you have built NuttX to
+       include debug symbols (by setting CONFIG_DEBUG_SYMBOLS=y in the
+       .config file).
+    2. The MCU must be halted prior to loading code using 'mon reset'
+       as described below.
+ 
+    OpenOCD will support several special 'monitor' commands.  These
+    GDB commands will send comments to the OpenOCD monitor.  Here
+    are a couple that you will need to use:
+  
+     (gdb) monitor reset
+     (gdb) monitor halt
+
+    NOTES:
+    1. The MCU must be halted using 'mon halt' prior to loading code.
+    2. Reset will restart the processor after loading code.
+    3. The 'monitor' command can be abbreviated as just 'mon'.
+
 Development Environment
 ^^^^^^^^^^^^^^^^^^^^^^^
 
diff --git a/nuttx/configs/lm3s6965-ek/tools/lm3s6965-ek.cfg b/nuttx/configs/lm3s6965-ek/tools/lm3s6965-ek.cfg
new file mode 100644
index 000000000..a82aa4cb9
--- /dev/null
+++ b/nuttx/configs/lm3s6965-ek/tools/lm3s6965-ek.cfg
@@ -0,0 +1,131 @@
+#
+# TI/Luminary Stellaris LM3S6965 Evaluation Kits
+#
+# http://www.luminarymicro.com/products/lm3s6965_ethernet_evaluation_kit.html
+
+# NOTE:  using the on-board FT2232 JTAG/SWD/SWO interface is optional!
+# so is using it in JTAG mode, as done here.
+
+# Interface configuration
+
+interface ft2232
+ft2232_device_desc "Stellaris Evaluation Board"
+ft2232_layout luminary_icdi
+ft2232_vid_pid 0x0403 0xbcd9
+
+# Board configuration
+
+# 20k working area
+set WORKAREASIZE 0x5000
+set CHIPNAME lm3s6965
+
+# Target configuration
+
+# Some devices have errata in returning their device class.
+# DEVICECLASS is provided as a manual override
+# Manual setting of a device class of 0xff is not allowed
+
+global _DEVICECLASS
+
+if { [info exists DEVICECLASS ] } {
+   set _DEVICECLASS $DEVICECLASS
+} else {
+   set _DEVICECLASS 0xff
+}
+
+# Luminary chips support both JTAG and SWD transports.
+# Adapt based on what transport is active.
+source [find target/swj-dp.tcl]
+
+# For now we ignore the SPI and UART options, which
+# are usable only for ISP style initial flash programming.
+
+if { [info exists CHIPNAME] } {
+   set  _CHIPNAME $CHIPNAME
+} else {
+   set  _CHIPNAME lm3s
+}
+
+# CPU TAP ID 0x1ba00477 for early Sandstorm parts
+# CPU TAP ID 0x2ba00477 for later SandStorm parts, e.g. lm3s811 Rev C2
+# CPU TAP ID 0x3ba00477 for Cortex-M3 r1p2 (on Fury, DustDevil)
+# CPU TAP ID 0x4ba00477 for Cortex-M3 r2p0 (on Tempest)
+# ... we'll ignore the JTAG version field, rather than list every
+# chip revision that turns up.
+if { [info exists CPUTAPID ] } {
+   set _CPUTAPID $CPUTAPID
+} else {
+   set _CPUTAPID 0x3ba00477
+}
+
+# SWD DAP, and JTAG TAP, take same params for now;
+# ... even though SWD ignores all except TAPID, and
+# JTAG shouldn't need anything more then irlen. (and TAPID).
+swj_newdap $_CHIPNAME cpu -irlen 4 -irmask 0xf \
+ 	-expected-id $_CPUTAPID -ignore-version
+
+if { [info exists WORKAREASIZE ] } {
+   set _WORKAREASIZE $WORKAREASIZE
+} else {
+   # default to 8K working area
+   set _WORKAREASIZE 0x2000
+}
+
+set _TARGETNAME $_CHIPNAME.cpu
+target create $_TARGETNAME cortex_m3 -chain-position $_CHIPNAME.cpu
+
+# 8K working area at base of ram, not backed up
+#
+# NOTE:  you may need or want to reconfigure the work area;
+# some parts have just 6K, and you may want to use other
+# addresses (at end of mem not beginning) or back it up.
+$_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE
+
+# JTAG speed ... slow enough to work with a 12 MHz RC oscillator;
+# LM3S parts don't support RTCK
+#
+# NOTE:  this may be increased by a reset-init handler, after it
+# configures and enables the PLL.  Or you might need to decrease
+# this, if you're using a slower clock.
+adapter_khz 500
+
+source [find mem_helper.tcl]
+
+$_TARGETNAME configure -event reset-start {
+	adapter_khz 500
+
+	#	
+	# When nRST is asserted on most Stellaris devices, it clears some of
+	# the debug state.  The ARMv7M and Cortex-M3 TRMs say that's wrong;
+	# and OpenOCD depends on those TRMs.  So we won't use SRST on those
+	# chips.  (Only power-on reset should affect debug state, beyond a
+	# few specified bits; not the chip's nRST input, wired to SRST.)
+	#
+	# REVISIT current errata specs don't seem to cover this issue.
+	# Do we have more details than this email?
+	#   https://lists.berlios.de/pipermail
+	#	/openocd-development/2008-August/003065.html
+	#
+
+	global _DEVICECLASS
+
+	if {$_DEVICECLASS != 0xff} {
+	   set device_class $_DEVICECLASS
+	} else {
+	   set device_class [expr (([mrw 0x400fe000] >> 16) & 0xff)]
+	}
+
+	if {$device_class == 0 || $device_class == 1 || $device_class == 3} {
+		# Sandstorm, Fury and DustDevil are able to use NVIC SYSRESETREQ
+		cortex_m3 reset_config sysresetreq
+	} else {
+		# Tempest and newer default to using NVIC VECTRESET
+		# this does mean a reset-init event handler is required to reset
+		# any peripherals
+		cortex_m3 reset_config vectreset
+	}
+}
+
+# flash configuration ... autodetects sizes, autoprobed
+flash bank $_CHIPNAME.flash stellaris 0 0 0 0 $_TARGETNAME
+
diff --git a/nuttx/configs/lm3s6965-ek/tools/oocd.sh b/nuttx/configs/lm3s6965-ek/tools/oocd.sh
new file mode 100755
index 000000000..28bcc48a7
--- /dev/null
+++ b/nuttx/configs/lm3s6965-ek/tools/oocd.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+#
+# See configs/lm3s6965-ek/README.txt for information about
+# this file.
+
+TOPDIR=$1
+USAGE="$0 <TOPDIR> [-d]"
+if [ -z "${TOPDIR}" ]; then
+	echo "Missing argument"
+	echo $USAGE
+	exit 1
+fi
+
+# Assume that OpenOCD was installed and at /usr/local/bin.  Uncomment
+# the following to run directly from the build directory
+#OPENOCD_PATH="/home/OpenOCD/openocd/src"
+#TARGET_PATH="/home/OpenOCD/openocd/tcl"
+OPENOCD_PATH="/usr/bin"
+TARGET_PATH="/usr/share/openocd/scripts"
+
+# Assume a Unix development environment.  Uncomment to use a Windows
+# like environment
+#OPENOCD_EXE=openocd.exe
+OPENOCD_EXE=openocd
+OPENOCD_CFG="${TOPDIR}/configs/lm3s6965-ek/tools/ek-lm3s6965.cfg"
+OPENOCD_ARGS="-f ${OPENOCD_CFG} -s ${TARGET_PATH}"
+
+if [ "X$2" = "X-d" ]; then
+	OPENOCD_ARGS=$OPENOCD_ARGS" -d3"
+	set -x
+fi
+
+if [ ! -d ${OPENOCD_PATH} ]; then
+	echo "OpenOCD path does not exist: ${OPENOCD_PATH}"
+	exit 1
+fi
+if [ ! -x ${OPENOCD_PATH}/${OPENOCD_EXE} ]; then
+	echo "OpenOCD does not exist: ${OPENOCD_PATH}/${OPENOCD_EXE}"
+	exit 1
+fi
+if [ ! -f ${OPENOCD_CFG} ]; then
+	echo "OpenOCD config file does not exist: ${OPENOCD_CFG}"
+	exit 1
+fi
+
+echo "Starting OpenOCD"
+cd ${OPENOCD_PATH} || { echo "Failed to CD to ${OPENOCD_PATH}"; exit 1; }
+${OPENOCD_EXE} ${OPENOCD_ARGS} &
+echo "OpenOCD daemon started"
+ps -ef | grep openocd
+echo "In GDB: target remote localhost:3333"
+