From 2153fc40b59d50dc8e48dee8afd2be61b2ea827f Mon Sep 17 00:00:00 2001 From: patacongo Date: Mon, 21 Jan 2013 16:56:29 +0000 Subject: [PATCH] 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 --- configs/lm3s6965-ek/README.txt | 80 +++++++++++++ configs/lm3s6965-ek/tools/lm3s6965-ek.cfg | 131 ++++++++++++++++++++++ configs/lm3s6965-ek/tools/oocd.sh | 52 +++++++++ drivers/lcd/README.txt | 72 +++++++----- include/nuttx/lcd/ug-2864ambag01.h | 1 + include/nuttx/lcd/ug-2864hsweg01.h | 1 + include/nuttx/lcd/ug-9664hswag01.h | 1 + 7 files changed, 311 insertions(+), 27 deletions(-) create mode 100644 configs/lm3s6965-ek/tools/lm3s6965-ek.cfg create mode 100755 configs/lm3s6965-ek/tools/oocd.sh diff --git a/configs/lm3s6965-ek/README.txt b/configs/lm3s6965-ek/README.txt index 77f034bf5d..94cf4d9021 100644 --- a/configs/lm3s6965-ek/README.txt +++ b/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/configs/lm3s6965-ek/tools/lm3s6965-ek.cfg b/configs/lm3s6965-ek/tools/lm3s6965-ek.cfg new file mode 100644 index 0000000000..a82aa4cb9e --- /dev/null +++ b/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/configs/lm3s6965-ek/tools/oocd.sh b/configs/lm3s6965-ek/tools/oocd.sh new file mode 100755 index 0000000000..28bcc48a79 --- /dev/null +++ b/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 [-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" + diff --git a/drivers/lcd/README.txt b/drivers/lcd/README.txt index 77ae536b2b..198be18a16 100644 --- a/drivers/lcd/README.txt +++ b/drivers/lcd/README.txt @@ -119,47 +119,65 @@ that support additional LCDs. LCD drivers in the configuration directory if they support some differ LCD interface (such as a parallel interface) that makes then less re-usable: - configs/compal_e99/src/ssd1783.c + SSD1783 Drivers: - SSD1783 + configs/compal_e99/src/ssd1783.c - configs/hymini-stm32v/src/ssd1289.c. See also drivers/lcd/ssd1298.c - above. + SSD1289 Drivers: + + configs/hymini-stm32v/src/ssd1289.c. See also drivers/lcd/ssd1298.c + above. + configs/stm32f4discovery/src/up_ssd1289.c. This examples is the + bottom half for the SSD1289 driver at drivers/lcd/ssd1289.c + configs/hymini-stm32v/src/ssd1289.c. See also drivers/lcd/ssd1298.c + above. + configs/shenzhou/src/up_ssd1289.c + + kwikstik-k40: - SSD1289 + configs/kwikstik-k40/src/up_lcd.c. Don't waste your time. This is + just a stub. - configs/kwikstik-k40/src/up_lcd.c. Don't waste your time. This is - just a stub. + Nokia LCD Drivers: - configs/olimex-lpc1766stk/src/up_lcd.c. This examples is the - bottom half for the SSD1289 driver at drivers/lcd/nokia6100.c. - This was never completedly debugged ... there are probably issues - with that nasty 9-bit SPI interfaces. + configs/olimex-lpc1766stk/src/up_lcd.c. This examples is the + bottom half for the driver at drivers/lcd/nokia6100.c. + This was never completedly debugged ... there are probably issues + with that nasty 9-bit SPI interfaces. - configs/sam3u-ek/src/up_lcd.c - - The SAM3U-EK developement board features a TFT/Transmissive color - LCD module with touch-screen, FTM280C12D, with integrated driver IC - HX8346. + HX8346: - configs/skp16c26/src/up_lcd.c. Untested alphanumeric LCD driver. + configs/sam3u-ek/src/up_lcd.c. The SAM3U-EK developement board features + a TFT/Transmissive color LCD module with touch-screen, FTM280C12D, + with integrated driver IC HX8346. - configs/stm3210e-eval/src/up_lcd.c + ILI93xx and Similar: - This driver supports the following LCDs: + configs/stm3210e-eval/src/up_lcd.c. This driver supports the following + LCDs: - 1. Ampire AM-240320LTNQW00H - 2. Orise Tech SPFD5408B - 3. RenesasSP R61580 + 1. Ampire AM-240320LTNQW00H + 2. Orise Tech SPFD5408B + 3. RenesasSP R61580 - configs/stm3220g-eval/src/up_lcd.c and configs/stm3240g-eval/src/up_lcd.c. - AM-240320L8TNQW00H (LCD_ILI9320 or LCD_ILI9321) and - AM-240320D5TOQW01H (LCD_ILI9325) + configs/stm3220g-eval/src/up_lcd.c and configs/stm3240g-eval/src/up_lcd.c. + AM-240320L8TNQW00H (LCD_ILI9320 or LCD_ILI9321) and + AM-240320D5TOQW01H (LCD_ILI9325) + configs/shenzhou/src/up_ili93xx.c. Another ILI93xx driver. - configs/stm32f4discovery/src/up_ssd1289.c. This examples is the - bottom half for the SSD1289 driver at drivers/lcd/ssd1289.c + OLEDs: + + configs/stm32f4discovery/src/up_ug2864ambag01.c + configs/stm32f4discovery/src/up_ug2864hsweg01.c + configs/zp214xpa/src/up_ug2864ambag01.c + + Alphnumeric Displays: + + configs/skp16c26/src/up_lcd.c. Untested alphanumeric LCD driver. + configs/stm32f4discovery/src/up_lcd1602.c graphics/ ========= See also the usage of the LCD driver in the graphics/ directory. + diff --git a/include/nuttx/lcd/ug-2864ambag01.h b/include/nuttx/lcd/ug-2864ambag01.h index deb5689812..86362d7736 100644 --- a/include/nuttx/lcd/ug-2864ambag01.h +++ b/include/nuttx/lcd/ug-2864ambag01.h @@ -1,5 +1,6 @@ /************************************************************************************** * include/nuttx/lcd/ug-2864ambag01.h + * * Driver for Univision UG-2864AMBAG01 OLED display (wih SH1101A controller) in SPI * mode * diff --git a/include/nuttx/lcd/ug-2864hsweg01.h b/include/nuttx/lcd/ug-2864hsweg01.h index bbefd39be0..e387419672 100644 --- a/include/nuttx/lcd/ug-2864hsweg01.h +++ b/include/nuttx/lcd/ug-2864hsweg01.h @@ -1,5 +1,6 @@ /************************************************************************************** * include/nuttx/lcd/ug-2864hsweg01.h + * * Driver for Univision UG-2864HSWEG01 OLED display (wih SSD1306 controller) in SPI * mode * diff --git a/include/nuttx/lcd/ug-9664hswag01.h b/include/nuttx/lcd/ug-9664hswag01.h index b470e0895e..a60b5ed67b 100644 --- a/include/nuttx/lcd/ug-9664hswag01.h +++ b/include/nuttx/lcd/ug-9664hswag01.h @@ -1,5 +1,6 @@ /**************************************************************************** * include/nuttx/lcd/ug-9664hswag01.h + * * Driver for the Univision UG-9664HSWAG01 Display with the Solomon Systech * SSD1305 LCD controller. *