diff options
Diffstat (limited to 'nuttx/configs/olimex-lpc1766stk/README.txt')
-rw-r--r-- | nuttx/configs/olimex-lpc1766stk/README.txt | 144 |
1 files changed, 88 insertions, 56 deletions
diff --git a/nuttx/configs/olimex-lpc1766stk/README.txt b/nuttx/configs/olimex-lpc1766stk/README.txt index 0978fdeca..5ca4a9504 100644 --- a/nuttx/configs/olimex-lpc1766stk/README.txt +++ b/nuttx/configs/olimex-lpc1766stk/README.txt @@ -137,7 +137,7 @@ Olimex LPC1766-STK development board But, referring to a different Olimex board, "Nokia 6100 LCD Display Driver," Revision 1, James P. Lynch ("Nokia 6100 LCD Display Driver.pdf") says: - + "The major irritant in using this display is identifying the graphics controller; there are two possibilities (Epson S1D15G00 or Philips PCF8833). The LCD display sold by the German Web Shop Jelu has a Leadis @@ -158,11 +158,11 @@ Olimex LPC1766-STK development board The LCD connects to the LPC1766 via SPI and two GPIOs. The two GPIOs are noted above: - + P1.21 is the SPI chip select, and P3.25 is the LCD reset P3.26 is PWM1 output used to control the backlight intensity. - + MISO0 and MOSI0 are join via a 1K ohm resistor so the LCD appears to be write only. @@ -239,7 +239,7 @@ IDEs NuttX is built using command-line make. It can be used with an IDE, but some effort will be required to create the project (There is a simple RIDE project in the RIDE subdirectory). - + Makefile Build -------------- Under Eclipse, it is pretty easy to set up an "empty makefile project" and @@ -334,7 +334,7 @@ NXFLAT Toolchain tools -- just the NXFLAT tools. The buildroot with the NXFLAT tools can be downloaded from the NuttX SourceForge download site (https://sourceforge.net/projects/nuttx/files/). - + This GNU toolchain builds and executes in the Linux or Cygwin environment. 1. You must have already configured Nuttx in <some-dir>/nuttx. @@ -398,7 +398,7 @@ LEDs LED1 LED2 Meaning ------- -------- -------------------------------------------------------------------- - OFF OFF Still initializing and there is no interrupt activity. + OFF OFF Still initializing and there is no interrupt activity. Initialization is very fast so if you see this, it probably means that the system is hung up somewhere in the initialization phases. OFF Glowing Still initializing (see above) but taking interrupts. @@ -408,7 +408,7 @@ LEDs OFF Flashing Ooops! We crashed before finishing initialization (or, perhaps after initialization, during an interrupt while the LPC17xx was sleeping -- see below). - + ON OFF The system has completed initialization, but is apparently not taking any interrupts. ON Glowing The OS successfully initialized and is taking interrupts (but, for @@ -426,7 +426,7 @@ LEDs NOTE: In glowing/glowing case, you get some good subjective information about the behavior of your system by looking at the level of the LED glow (or better, by connecting O-Scope and calculating the actual duty): - + 1. The intensity of the glow is determined by the duty of LED on/off toggle -- as the ON period becomes larger with respect the OFF period, the LED will glow more brightly. @@ -442,7 +442,7 @@ LEDs When my LPC1766 sits IDLE -- doing absolutely nothing but processing timer interrupts -- I see the following: - + 1. LED1 glows dimly due to the timer interrupts. 2. But LED2 is even more dim! The LED ON time excludes the time processing the interrupt that re-awakens the processing. So this tells me that the LPC1766 is @@ -471,24 +471,24 @@ Using OpenOCD and GDB with an FT2232 JTAG emulator ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Downloading OpenOCD - + You can get information about OpenOCD here: http://openocd.berlios.de/web/ and you can download it from here. http://sourceforge.net/projects/openocd/files/. To get the latest OpenOCD with more mature lpc17xx, you have to download from the GIT archive. - + git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd At present, there is only the older, frozen 0.4.0 version. These, of course, may have changed since I wrote this. - + Building OpenOCD under Cygwin: You can build OpenOCD for Windows using the Cygwin tools. Below are a few notes that worked as of November 7, 2010. Things may have changed by the time you read this, but perhaps the following will be helpful to you: - + 1. Install Cygwin (http://www.cygwin.com/). My recommendation is to install everything. There are many tools you will need and it is best just to waste a little disk space and have everthing you need. Everything will @@ -505,23 +505,23 @@ Using OpenOCD and GDB with an FT2232 JTAG emulator CDM20802 WHQL Certified.zip $ mkdir ftd2xx $ cd ftd2xx - $ unzip ..CDM20802\ WHQL\ Certified.zip + $ unzip ..CDM20802\ WHQL\ Certified.zip Archive: CDM20802 WHQL Certified.zip ... 3. Get the latest OpenOCD source - + $ pwd /home/OpenOCD $ git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd - + You will then have the source code in /home/OpenOCD/openocd 4. Build OpenOCD for the FT22322 interface $ pwd /home/OpenOCD/openocd - $ ./bootstrap + $ ./bootstrap Jim is a tiny version of the Tcl scripting language. It is needed by more recent versions of OpenOCD. Build libjim.a using the following @@ -557,7 +557,7 @@ Using OpenOCD and GDB with an FT2232 JTAG emulator I have been using the Olimex ARM-USB-OCD JTAG debugger with the LPC1766-STK (http://www.olimex.com). OpenOCD requires a configuration file. I keep the one I used last here: - + configs/olimex-lpc1766stk/tools/olimex.cfg However, the "correct" configuration script to use with OpenOCD may @@ -571,13 +571,13 @@ Using OpenOCD and GDB with an FT2232 JTAG emulator flash bank $_FLASHNAME lpc2000 0x0 0x80000 0 0 $_TARGETNAME ... To: - + flash bank $_FLASHNAME lpc2000 0x0 0x40000 0 0 $_TARGETNAME ... - + 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/olimex-lpc1766stk/tools/olimex.cfg @@ -623,11 +623,11 @@ Using OpenOCD and GDB with an FT2232 JTAG emulator FLASH. 3. 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 @@ -710,7 +710,7 @@ Olimex LPC1766-STK Configuration Options the delay actually is 100 seconds. Individual subsystems can be enabled: - + CONFIG_LPC17_MAINOSC=y CONFIG_LPC17_PLL0=y CONFIG_LPC17_PLL1=n @@ -799,7 +799,7 @@ Olimex LPC1766-STK Configuration Options LPC17xx USB Device Configuration CONFIG_LPC17_USBDEV_FRAME_INTERRUPT - Handle USB Start-Of-Frame events. + Handle USB Start-Of-Frame events. Enable reading SOF from interrupt handler vs. simply reading on demand. Probably a bad idea... Unless there is some issue with sampling the SOF from hardware asynchronously. @@ -898,7 +898,7 @@ Where <subdir> is one of the following: 1. Support for FAT long file names is built-in but can easily be removed if you are concerned about Microsoft patent issues (see the section "FAT Long File Names" in the top-level COPYING file). - + CONFIG_FS_FAT=y CONFIG_FAT_LCNAMES=y <-- Long file name support CONFIG_FAT_LFN=y @@ -908,7 +908,7 @@ Where <subdir> is one of the following: 2. You may also want to define the following in your configuration file. Otherwise, you will have not feedback about what is going on: - + CONFIG_DEBUG=y CONFIG_DEBUG_VERBOSE=y CONFIG_DEBUG_FTPC=y @@ -918,7 +918,7 @@ Where <subdir> is one of the following: HID keyboard class driver using the test logic in apps/examples/hidkbd. NOTES: - + 1. This configuration uses the mconf-based configuration tool. To change this configuration using that tool, you should: @@ -954,7 +954,7 @@ Where <subdir> is one of the following: Configuration Notes: NOTES: - + 1. This configuration uses the mconf-based configuration tool. To change this configuration using that tool, you should: @@ -1003,15 +1003,15 @@ Where <subdir> is one of the following: 1. Configure and build the slip-httpd configuration. 2. Connect to a Linux box (assuming /dev/ttyS0) 3. Reset on the target side and attach SLIP on the Linux side: - + $ modprobe slip $ slattach -L -p slip -s 57600 /dev/ttyS0 & - + This should create an interface with a name like sl0, or sl1, etc. Add -d to get debug output. This will show the interface name. NOTE: The -L option is included to suppress use of hardware flow - control. This is necessary because I haven't figured out how to + control. This is necessary because I haven't figured out how to use the UART1 hardware flow control yet. NOTE: The Linux slip module hard-codes its MTU size to 296. So you @@ -1038,7 +1038,7 @@ Where <subdir> is one of the following: NOTE: This configurat only works with VERBOSE debug disabled. For some reason, certain debug statements hang(?). - + NOTE: This example does not use UART1's hardware flow control. UART1 hardware flow control is partially implemented but does not behave as expected. It needs a little more work. @@ -1097,35 +1097,67 @@ Where <subdir> is one of the following: Hmmm.. I probably should set up an NSH script to just mount /dev/mmcsd0 at /mnt/sdcard each time the board boots. - This program has been verified against the rzsz programs running on a - Linux PC. To send a file to the PC, first make sure that the serial - port is configured to work with the board: + 3. Sending Files from the Target to the Linux Host PC + + This program has been verified against the rzsz programs running on a + Linux PC. To send a file to the PC, first make sure that the serial + port is configured to work with the board: + + $ sudo stty -F /dev/ttyS0 57600 + $ sudo stty -F /dev/ttyS0 + + Start rz on the Linux host: + + $ sudo rz </dev/ttyS0 >/dev/ttyS0 + + You can add the rz -v option multiple times, each increases the level + of debug output. + + NOTE: The NuttX Zmodem does sends rz\n when it starts in compliance with + the Zmodem specification. On Linux this, however, seems to start some + other, incompatible version of rz. You need to start rz manually to + make sure that the correct version is selected. You can tell when this + evil rz/sz has inserted itself because you will see the '^' (0x5e) + character replacing the standard Zmodem ZDLE character (0x19) in the + binary data stream. + + If you don't have the rz command on your Linux box, the package to + install rzsz (or possibily lrzsz). + + Then on the target: + + > sz -d /dev/ttyS1 <filename> + + Where filename is the full path to the file to send (i.e., it begins + with the '/' character). + + 4. Receiving Files on the Target from the Linux Host PC + + To send a file to the target, first make sure that the serial port on + the host is configured to work with the board: + + $ sudo stty -F /dev/ttyS0 57600 + $ sudo stty -F /dev/ttyS0 - $ sudo stty -F /dev/ttyS0 57600 - $ sudo stty -F /dev/ttyS0 + Start rz on the on the target: - start rz on the Linux host: + nsh> rz -d /dev/ttyS1 - $ sudo rz </dev/ttyS0 >/dev/ttyS0 + Then use the sz command on Linux to send the file to the target: - You can add the rz -v option multiple times, each increases the level - of debug output. + $ sudo sz <filename> t </dev/ttyS0 >/dev/ttyS0 - NOTE: The NuttX Zmodem does sends rz\n when it starts in compliance with - the Zmodem specification. On Linux this, however, seems to start some - other, incompatible version of rz. You need to start rz manually to - make sure that the correct version is selected. You can tell when this - evil rz/sz has inserted itself because you will see the '^' (0x5e) - character replacing the standard Zmodem ZDLE character (0x19) in the - binary data stream. + Where <filename> is the file that you want to send. - If you don't have the rz command on your Linux box, the package to - install rzsz (or possibily lrzsz). + The resulting file will be found where you have configured the Zmodem + "sandbox" via CONFIG_SYSTEM_ZMODEM_MOUNTPOINT, in this case at + /mnt/sdcard. - Then on the target: + You can add the az -v option multiple times, each increases the level + of debug output. If you want to capture the Linux rz output, then + re-direct stderr to a log file by adding 2>az.log to the end of the + rz command. - > sz -d /dev/ttyS1 <filename> + If you don't have the az command on your Linux box, the package to + install rzsz (or possibily lrzsz). - Where filename is the full path to the file to send (i.e., it begins - with the '/' character). -
\ No newline at end of file |