LPCwareアーカイブコンテンツ

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

LPCware Archive Content

ディスカッション

ソート順:
Introduction The LPC USB serial I/O (LPCUSBSIO) is a generic API provided to PC applications programmer to develop applications to communicate with serial I/O devices connected to LPC micro-controller. LPCUSBIO library converts all API calls into USB messages which are transferred to LPC micro-controller, which in turn communicates with serial devices using I2C, SPI and GPIO interfaces. To make the USB device install free on host systems LPCUSBSIO uses USB-HID class as transport mechanism. HID class is natively supported by most commercially available host operating systems.    Architecture The framework uses HID_API , a multi-platform library which allows an application to interface with USB HID-Class devices on Windows, Linux, and Mac OS X. The following figure shows how the components of the system are typically organized. The PC/Host may be desktop/laptop machine or an embedded system. The LPC micro-controller and the I2C device would usually be on the same PCB. The LPC micro-controller will operate in I2C master mode. All the I2C device connected to the bus should have unique address on bus. I2C devices that support configurable addresses will have pins which can be hard-wired to give a device an appropriate address; this information may be found in the datasheet of the I2C device chip. LPCUSBSIO Architecture
記事全体を表示
If you accidentally erase the kickstart or S1L boot loaders on the Embedded Artists LPC3250 board, this procedure can be used to restore them. Note the boot loaders provided in this restoration method might be newer than the versions provided with the Embedded Artists board. The original versions of the boot loaders can also be downloaded from the Embedded Artists 's website when you register your board.   Restoration of the boot loaders on the board require no special hardware (ie, JTAG) and are performed with boot loaders and tools built or included in the LPC32x0 Common Driver Library. However, you will need a PC with a USB port to perform the update procedure.   Restoring the kickstart loader and is a 2-step process. The kickstart loader is restored first and then is restored. The serial loader is used to transfer the application and the burner images (which is used to program the application into NAND FLASH). The LPC32x0 will automatically burn the image into NAND FLASH after it has been downloaded and then provide a status.   Step 1: Download the pre-built boot software and restoration images for the Embedded Artists LPC3250 board from the Resources page. Step 2: Extract the files on a Windows based PC Step 3: Connect a USB cable between the Embedded Artists boards USB serial connector and the PC. Power up the board and install and USB serial drivers if necessary. These drivers are included with the software included with the board. Step 4: Start the Serial loader software (LPC3250_Loader.exe) included in the pre-built boot software package. Step 5: Setup the 'Primary boot (IRAM)' file in the Serial loader to the burner_kickstart_nand_large_block_rvw.bin file. Setup the 'Secondary Executable (SDRAM)' file in the Serial loader to the kickstart_nand_large_block_rvw.bin file. Verify that the Comport control selection matches the COM part on the PC that is connected to the Embedded Artists board.   NOTE: The pre-built binaries may have slightly different names than those listed in steps 5 and 7, depending on the tool used to build the binaries. If the binaries were build with GNU instead of Realview, the 'rvw' field in each name will contain the 'gnu' identified instead. Change the filenames as necessary for you binaries you have.   Step 6: Press the 'Load bin's / Start primary' button on the Serial loader and power on the board. The burner image and the kickstart loader image should transfer to the board and the kickstart loader will then be programmed into NAND FLASH block 0 for boot from the boot ROM by the burner application. After the files have transferred, press the 'Enable terminal mode' button to see the program status. In the Status / Terminal output window of the Serial loader tool, you should see the following output. Waiting for BootID .. 5 .. found! Sending 'A' .. done! Expect 2-nd BootId .. 5 .. found! Sending 'U','3'.. done! Expect 'R' .. R .. found! Sending startaddress .. done! Sending size .. done! Sending code .. done! --- Loading Secondary executable --- Wait for 'X' .. X .. found! -- Sending command .. p ..done! Sending startaddress .. done! Sending size .. done! Wait for acceptance from primary boot .. o ..OK! Sending code .. done! Expect final 't' .. t .. found, ---- Secondary Executable loaded. --- --- Enabling terminal mode --- Formatting blocks... Format complete Writting kickstart into flash... Verifing data......Successfully NAND flash is programmed Successfully     Step 7: Setup the 'Primary boot (IRAM)' file in the Serial loader to the burner_s1app_nand_large_block_rvw.bin file. Setup the 'Secondary Executable (SDRAM)' file in the Serial loader to the s1l_from_kick_rvw.bin file. Verify that the Comport control selection matches the COM part on the PC that is connected to the Embedded Artists board.   Step 8: Press the 'Load bin's / Start primary' button on the Serial loader and reset the board. The burner image and the image should transfer to the board and will then be programmed into NAND FLASH block 1 (and on) for boot from the kickstart loader. After the files have transferred, press the 'Enable terminal mode' button to see the program status. In the Status Terminal output window of the Serial loader tool, you should see the following output.     Waiting for BootID .. 5 .. found! Sending 'A' .. done! Expect 2-nd BootId .. 5 .. found! Sending 'U','3'.. done! Expect 'R' .. R .. found! Sending startaddress .. done! Sending size .. done! Sending code .. done! --- Loading Secondary executable --- Wait for 'X' .. X .. found! -- Sending command .. p ..done! Sending startaddress .. done! Sending size .. done! Wait for acceptance from primary boot .. o ..OK! Sending code .. done! Expect final 't' .. t .. found, ---- Secondary Executable loaded. --- --- Enabling terminal mode --- Formatting blocks... Format complete Writting S1 image into flash... NAND flash is programmed Successfully Step 8: Close the Serial loader and open a terminal program, then reset the board Close the serial loader tool and open a terminal program such as Teraterm. Reset the board and should start. 5 Embedded Artist 3250 Board Build date: May 21 2010 15:12:06 Autoboot in progress, press any key to stop ea3250 >
記事全体を表示
This is the uCOSIII port for LPC43XX based hitex board with revision A4. The BSP and the applicaton code for the port is attached below. The tools supported to build the package are: a) Keil uVision. It has been tested with V4.53.0.0 There are three attachments on the page containing i)The BSP,application and the CPU port files. ii)OS port for the core. iii) A png file showing the directory structure of the project. Here is a set of instructions to build and test the port: 1) Unzip the uCOSIII_Port.zip attachment and you should have "EvalBoards" and "uC-CPU" folders.Place them in your convinient folder. 2) Download uCOSIII source from http://micrium.com/page/downloads/download_os-III_source_code 3)You should now have a "Source" folder containing uCOSIII sources. Place this folder in The directory structure should look like the one shown in the attached png file. 4)Now, find the project file at 5)Double click "hitex4350_tcpecho_uCOSIII.uvproj" which opens the project. Go ahead and build the project for the required target. 6) Connect the Target "Hitex board" with J-Link. And Power it ON. You can either power it with USB or external supply. The default project is setup to use JLink. 7) You can download the image to the IRAM or flash depending on the target you have built. 😎 Run the image, you should be able to ping and telnet it.( This project uses static IP, so change your IP according to your need in the main.c file before building the image)
記事全体を表示
Before building u-boot, you'll need a machine that can run Linux (such as Fedora or Ubuntu). You can setup a Virtual Machine and install Linux on it if you don't have access to a physical Linux machine. 1. Start by downloading the u-boot source code at http://www.denx.de/wiki/U-Boot/WebHome. Unzip the source code into a directory on your machine. The patch has been built against the 2011.06 version of the u-boot source, so be sure to get the correct version. 2. Get the LPC177x_8x u-boot patch the attached file. 3. Apply the patch to the u-boot source code using the following command in the u-boot source directory. ubuntu:~/dev/lpc1788/u-boot-2011.06$ patch -p1 < u-boot-2011.06-ea1788_v1_00.patch patching file arch/arm/cpu/cortex-m3/config.mk patching file arch/arm/cpu/cortex-m3/cpu.c patching file arch/arm/cpu/cortex-m3/lpc17xx/clocks.c patching file arch/arm/cpu/cortex-m3/lpc17xx/common.c patching file arch/arm/cpu/cortex-m3/lpc17xx/flash.c patching file arch/arm/cpu/cortex-m3/lpc17xx/gpio.c patching file arch/arm/cpu/cortex-m3/lpc17xx/iaplib.c patching file arch/arm/cpu/cortex-m3/lpc17xx/iocon.c patching file arch/arm/cpu/cortex-m3/lpc17xx/Makefile patching file arch/arm/cpu/cortex-m3/lpc17xx/serial.c patching file arch/arm/cpu/cortex-m3/lpc17xx/timer.c patching file arch/arm/cpu/cortex-m3/Makefile patching file arch/arm/cpu/cortex-m3/mpu.c patching file arch/arm/cpu/cortex-m3/nvic.c patching file arch/arm/cpu/cortex-m3/start.S patching file arch/arm/cpu/cortex-m3/u-boot.lds patching file arch/arm/include/asm/arch-cortex-m3/cortex-m3.h patching file arch/arm/include/asm/arch-lpc17xx/hardware.h patching file arch/arm/include/asm/arch-lpc17xx/lpc17_clock_checks.h patching file arch/arm/include/asm/arch-lpc17xx/lpc17_clocks.h patching file arch/arm/include/asm/arch-lpc17xx/lpc17_gpio.h patching file arch/arm/include/asm/arch-lpc17xx/lpc17_iaplib.h patching file arch/arm/include/asm/arch-lpc17xx/lpc17_iocon.h patching file arch/arm/include/asm/arch-lpc17xx/lpc17_mac.h patching file arch/arm/include/asm/arch-lpc17xx/lpc17_regs.h patching file arch/arm/lib/board.c patching file board/nxp/ea1788/config.mk patching file board/nxp/ea1788/ea1788.c patching file board/nxp/ea1788/Makefile patching file board/nxp/ea1788/mem.c patching file board/nxp/ea1788/mpu_setup.c patching file board/nxp/ea1788/nand.c patching file board/nxp/ea1788/net.c patching file board/nxp/ea1788/pins.c patching file include/configs/ea1788.h patching file Makefile ubuntu:~/dev/lpc1788/u-boot-2011.06$ 4. Download the Code Sourcery GNU Lite tools for Linux (http://www.lpcware.com/content/tools/code-sourcery-codebench) and untar the tools into a directory. 5. Add the Code Sourcery GNU tools to your path as follows. Change the directory to where your tools have been installed. export PATH=$PATH:$/home/user/dev/arm-2011.03/bin 6. Add several environment variables to your shell with the following commands. Like the path above, make sure the CROSS_COMPILE path is correct. export CROSS_COMPILE=/home/user/dev/arm-2011.03/bin/arm-none-eabi- export ARCH=arm 7. Switch into the u-boot directory and type 'make ea1788_config' to configure u-boot for the EA1788 board. ubuntu:~/dev/lpc1788/u-boot-2011.06-lpc1788$ make ea1788_config awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }' boards.cfg > .boards.depend Configuring for ea1788 board... ubuntu:~/dev/lpc1788/u-boot-2011.06-lpc1788$ 8. Before building the u-boot binary, an additional tool must be added to your path to generate the word 7 checksum value in the u-boot binary. Without this, u-boot won't boot on the board. You can get this tool at attached files. Add the path that the tool is located in to your PATH environment variable similar to step 5 above. 9. Type 'make to build the u-boot binaries. ubuntu:~/dev/lpc1788/u-boot-2011.06-lpc1788$ make Generating include/autoconf.mk Generating include/autoconf.mk.dep /home/usb10132/dev/lpc1788/arm-2011.03/bin/arm-none-eabi-gcc -DDO_DEPS_ONLY \ -g  -Os   -fno-common -ffixed-r8 -msoft-float   -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0xA1F80000 -I/home/usb10132/dev/lpc1788/u-boot-2011.06-lpc1788/include -fno-builtin -ffreestanding -nostdinc -isystem /home/usb10132/dev/lpc1788/arm-2011.03/bin/../lib/gcc/arm-none-eabi/4.5.2/include -pipe  -DCONFIG_ARM -D__ARM__ -marm  -mabi=aapcs-linux -mno-thumb-interwork -march=armv7-m -mthumb -Os -static-libgcc -fpic -mtune=cortex-m3 -nostdlib -Wall -Wstrict-prototypes -fno-stack-protector   \ -o lib/asm-offsets.s lib/asm-offsets.c -c -S ... ... ... /home/usb10132/dev/lpc1788/arm-2011.03/bin/arm-none-eabi-objcopy -O srec u-boot u-boot.srec /home/usb10132/dev/lpc1788/arm-2011.03/bin/arm-none-eabi-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin ./lpc17_fcg u-boot.bin u-boot-lpc.bin File u-boot.bin loaded with size 125572 bytes Word 0: 0x1000ff90 Word 1: 0x00000161 Word 2: 0x00000135 Word 3: 0x00000139 Word 4: 0x0000013d Word 5: 0x00000141 Word 6: 0x00000145 Word 7: 0xeffef8de (cksum total: 0x00000000) File u-boot-lpc.bin created with size 125572 bytes /home/usb10132/dev/lpc1788/arm-2011.03/bin/arm-none-eabi-objcopy --gap-fill=0xff -O ihex u-boot-lpc.bin u-boot-lpc.hex -I binary /home/usb10132/dev/lpc1788/arm-2011.03/bin/arm-none-eabi-objdump -d u-boot > u-boot.dis ubuntu:~/dev/lpc1788/u-boot-2011.06-lpc1788$ After about a minute, you should get the binary and hex file used for programming the board. The hex file is used with the Flash Magic tool, while the binary can be used directly with u-boot to update itself after u-boot has been installed. The files are called u-boot-lpc.hex and u-boot-lpc.bin
記事全体を表示
For small and large page NAND devices, the data is typically organized as follows:   Small page NAND FLASH (factory) Bytes 0 - 511        : Main data payload area Bytes 512 - 515      : Spare data area, 4 bytes Bytes 516 - 517      : Factory bad block marker area (typical) Bytes 518 - 527      : Spare data area, 10 bytes   Large page NAND FLASH (factory) Bytes 0 - 2047       : Main data payload area Bytes 2048 - 2048    : Factory bad block marker area (typical) Bytes 2049 - 2111    : Spare data area, 63 bytes   The LPC32x0 MLC NAND controller uses the following storage approach when used with ECC: Small page NAND FLASH, MLC NAND controller with ECC Bytes 0 - 517        : Main data payload area Bytes 518 - 527      : ECC data area   Large page NAND FLASH, MLC NAND controller with ECC Bytes 0 - 517        : Main data payload area, subpage 1 Bytes 518 - 527      : ECC data area, subpage 1 Bytes 528 - 1045     : Main data payload area, subpage 2 Bytes 1046 - 1055    : ECC data area, subpage 2 Bytes 1056 - 1573    : Main data payload area, subpage 3 Bytes 1574 - 1583    : ECC data area, subpage 3 Bytes 1584 - 2101    : Main data payload area, subpage 4 Bytes 2102 - 2111    : ECC data area, subpage 4   The LPC32x0 SLC NAND controller uses the following storage approach when used with ECC: Small page NAND FLASH, SLC NAND controller with ECC Bytes 0 - 255        : Main data payload area, subpage 1 Bytes 256 - 511      : Main data payload area, subpage 2 Bytes 512 - 515      : Spare data area, bytes 0 - 3 Bytes 516 - 517      : Bad block marker Bytes 518 - 521      : Spare data area, bytes 4 - 7 Bytes 522 - 524      : ECC data area, subpage 1 Bytes 525 - 527      : ECC data area, subpage 2   Large page NAND FLASH, SLC NAND controller with ECC Bytes 0 - 255        : Main data payload area, subpage 1 Bytes 256 - 511      : Main data payload area, subpage 2 Bytes 512 - 767      : Main data payload area, subpage 3 Bytes 768 - 1023     : Main data payload area, subpage 4 Bytes 1024 - 1279    : Main data payload area, subpage 5 Bytes 1280 - 1535    : Main data payload area, subpage 6 Bytes 1536 - 1791    : Main data payload area, subpage 7 Bytes 1792 - 2047    : Main data payload area, subpage 8 Bytes 2048 - 2049    : Bad block marker Bytes 2050 - 2087    : Spare data area, 38 bytes Bytes 2088 - 2090    : ECC data area, subpage 1 Bytes 2091 - 2093    : ECC data area, subpage 2 Bytes 2094 - 2096    : ECC data area, subpage 3 Bytes 2097 - 2099    : ECC data area, subpage 4 Bytes 2100 - 2102    : ECC data area, subpage 5 Bytes 2103 - 2105    : ECC data area, subpage 6 Bytes 2106 - 2108    : ECC data area, subpage 7 Bytes 2109 - 2111    : ECC data area, subpage
記事全体を表示
Introduction The Universal Serial Bus (USB) is the most-successful interface in personal computing today. Fast, reliable, and easy-to-use, you will find this interface everywhere — on personal computers, computer peripherals, monitors, mobile devices, audio and video equipment, and most other consumer electronic products.   NXP leads the market in USB-equipped ARM microcontrollers providing more than 80 options for Cortex-M4, Cortex-M3, Cortex-M0, ARM9, and ARM7 microcontrollers (see comparison table and products below). NXP's portfolio of high-speed and full-speed device/host/OTG USB-enabled microcontrollers offers special USB features (like on-chip HS PHY and ROM drivers), free software, and comprehensive support to help you move quickly from design concept to production.   TechOnLine Rapid USB development on Cortex-M microcontrollers webinar (Sep 7, 2011) NXP Advantages NXP's microcontroller portfolio features the latest USB technologies, including full- and high-speed USB 2.0 device, host, and On-The-Go (OTG) functions. NXP supports all four transfer types: control, interrupt, bulk, and, in particular, isochronous, which is required for streaming audio. NXP MCUs provide designers a range of special USB features that improve overall performance and speed time-to-market: Fully-Certified USB Products On-Chip ROM Drivers Integrated Hi-Speed and/or Full-Speed PHY Free USB Host and Device Software Additional USB Features Fully-Certified USB Products NXP is a leading member of the USB-IF, the organization that maintains the USB specifications and verifies USB compliance. NXP's USB-equipped ARM MCUs are submitted for certification, so designers can be certain that their systems will deliver the best in reliability and plug-and-play operation. As of the end of 2008, most of our USB 2.0-based processors with host and device functions have been certified; the OTG function is in-process. A complete list of compliant products appears on the USB-IF web site, www.usb.org. On-Chip USB ROM Drivers NXP's on-board USB ROM drivers pack the entire USB stack, USB classes, and low-level drivers right into the microcontroller's ROM, eliminating the need to develop and debug this complex software yourself. Placing the USB drivers in the ROM frees up valuable memory space that you can then use for your application. These drivers have been thoroughly tested by NXP and outside test houses and are used to gain USB logo certification after passing the rigorous testing requirements at USB-IF. Integrated Hi-Speed and/or Full-Speed PHY A full-speed or high-speed PHY is integrated into NXP's USB microcontrollers and provides the bridge between the digital and modulated parts of the interface. The integration of the PHY on the MCU saves component cost and simplifies system design. For example, the LPC1800 and LPC4300 microcontrollers support two channels of High-Speed USB 2.0 Host/Device/OTG and have an on-chip High-Speed PHY. Free USB Host and Device Software USB development doesn't have to be expensive or difficult. To help you save time and money, NXP provides complete ready-to-go USB example applications for host and device modes that work out of the box on multiple tool chains — all at no charge. In addition to NXP's own complimentary USB packages, NXP partners with leading software companies to provide state-of-the-art USB firmware. For a complete list of USB software options, please see the Support section of this page. Additional USB Features NXP's additional USB features include the following: Host controllers are OHCI-/EHCI-compliant. Dedicated DMA lets the USB interface operate with minimal CPU intervention. SoftConnect™ uses software to determine when a USB device will connect to the bus. GoodLink™ uses an LED to indicate that a USB device has been enumerated and configured on the bus. (To save power, the LED is turned off during suspend.) Double-buffering maximizes throughput on bulk and isochronous endpoints. Multiple USB ports let devices be configured as hosts, devices, or both. USB data buffer provides flexible configuration of endpoint FIFO sizes. Products NXP offers more than 80 USB MCU options for Cortex-M0, Cortex-M3, Cortex-M4, ARM9, and ARM7 microcontrollers (see the comparison table and products below). NXP MCUs special USB features include: Comparison Table Core Product On-Chip Controller No. of Cntrls No. of Ports On-chip PHY Certified Device Host OTG ARM7TDMI-S LPC2141 FS - - 1 1 Device FS LPC2142 FS - - 1 1 Device FS LPC2144 FS - - 1 1 Device - LPC2146 FS - - 1 1 Device - LPC2148 FS - - 1 1 Device FS LPC2158 FS - - 1 1 Device - LPC2361 FS FS FS 1 1 Device, Host FS LPC2362 FS FS FS 1 1 Device, Host FS LPC2364 FS - - 1 1 Device FS LPC2366 FS - - 1 1 Device FS LPC2368 FS - - 1 1 Device FS LPC2378 FS - - 1 1 Device FS LPC2387 FS FS FS 1 1 Device, Host FS LPC2388 FS FS FS 1 2 Device, Host FS LPC2420 FS FS FS 1 2 Device, Host - LPC2458 FS FS FS 1 2 Device, Host - LPC2460 FS FS FS 1 2 Device, Host - LPC2468 FS FS FS 1 2 Device, Host FS LPC2470 FS FS FS 1 2 Device, Host - LPC2478 FS FS FS 1 2 Device, Host - LPC2880 HS - - 1 1 Device HS LPC2888 HS - - 1 1 Device HS ARM720T LH79524 FS - - 1 1 Device - LH79525 FS - - 1 1 Device - ARM922T LH7A404 FS FS - 1 3 (2 host) Device, Host - LH7A400 FS - - 1 1 Device - ARM968 LPC2921 FS - - 1 1 Device - LPC2923 FS - - 1 1 Device - LPC2925 FS - - 1 1 Device - LPC2926 FS FS 1 1 Device LPC2927 FS - FS 1 1 Device - LPC2929 FS - FS 1 1 Device FS LPC2930 FS FS FS 1 2 Device, Host - LPC2939 FS FS FS 1 2 Device, Host - ARM926EJ-S LPC3180/01 FS FS FS 1 1 - - LPC3220 FS FS FS 1 1 - - LPC3230 FS FS FS 1 1 - - LPC3240 FS FS FS 1 1 - - LPC3250 FS FS FS 1 1 - - LPC3130 HS HS HS 1 1 Device, Host, OTG - LPC3131 HS HS HS 1 1 Device, Host, OTG HS LPC3151 HS HS HS 1 1 Device, Host, OTG - LPC3152 HS HS HS 1 1 Device, Host, OTG HS LPC3153 HS HS HS 1 1 Device, Host, OTG - LPC3154 HS HS HS 1 1 Device, Host, OTG - Cortex-M3 LPC1342 FS - - 1 1 Device FS LPC1343 FS - - 1 1 Device FS LPC1345 FS - - 1 1 Device - LPC1346 FS - - 1 1 Device - LPC1347 FS - - 1 1 Device - LPC1547 FS - - 1 1 Device - LPC1548 FS - - 1 1 Device - LPC1549 FS - - 1 1 Device FS LPC1751 FS - - 1 1 Device FS LPC1752 FS - - 1 1 Device - LPC1754 FS FS FS 1 1 Device, Host - LPC1756 FS FS FS 1 1 Device, Host - LPC1758 FS FS FS 1 1 Device, Host - LPC1759 FS FS FS 1 1 Device, Host - LPC1764 FS - - 1 1 Device - LPC1765 FS FS FS 1 1 Device, Host - LPC1766 FS FS FS 1 1 Device, Host - LPC1768 FS FS FS 1 1 Device, Host FS LPC1769 FS FS FS 1 1 Device, Host - LPC1774 FS - - 1 1 Device - LPC1776 FS FS FS 1 1 Device, Host - LPC1777 FS FS FS 1 1 Device, Host - LPC1778 FS FS FS 1 1 Device, Host - LPC1785 FS FS FS 1 1 Device, Host - LPC1786 FS FS FS 1 1 Device, Host - LPC1787 FS FS FS 1 1 Device, Host - LPC1788 FS FS FS 1 1 Device, Host - LPC1820 HS HS HS 1 1 Device, Host - LPC1822 HS HS HS 1 1 Device, Host - LPC1823 HS HS HS 1 1 Device, Host - LPC1825 HS HS HS 1 1 Device, Host - LPC1827 HS HS HS 1 1 Device, Host - LPC1830 HS HS HS 2 2 Device, Host - LPC1833 HS HS HS 2 2 Device, Host - LPC1837 HS HS HS 2 2 Device, Host FS LPC1850 HS HS HS 2 2 Device, Host FS LPC1853 HS HS HS 2 2 Device, Host FS LPC1857 HS HS HS 2 2 Device, Host FS Cortex-M4 LPC4072 FS FS FS 1 2 Device, Host, OTG - LPC4074 FS FS FS 1 2 Device, Host, OTG - LPC4076 FS FS FS 1 2 Device, Host, OTG - LPC4078 FS FS FS 1 2 Device, Host, OTG - LPC4088 FS FS FS 1 2 Device, Host, OTG - LPC4320 HS HS HS 1 1 Device, Host, OTG - LPC4320 HS HS HS 1 1 Device, Host, OTG LPC4322 HS HS HS 1 1 Device, Host, OTG - LPC4323 HS HS HS 1 1 Device, Host, OTG - LPC4325 HS HS HS 1 1 Device, Host, OTG - LPC4327 HS HS HS 1 1 Device, Host, OTG - LPC4330 HS HS HS 2 2 Device, Host, OTG - LPC4333 HS HS HS 2 2 Device, Host, OTG - LPC4337 HS HS HS 2 2 Device, Host, OTG - LPC4350 HS HS HS 2 2 Device, Host, OTG - LPC4353 HS HS HS 2 2 Device, Host, OTG - LPC4357 HS HS HS 2 2 Device, Host, OTG - Cortex-M0 LPC11U12 FS - - 1 1 Device - LPC11U13 FS - - 1 1 Device - LPC11U14 FS - - 1 1 Device FS LPC11U23 FS - - 1 1 Device - LPC11U24 FS - - 1 1 Device LS, FS LPC11U34 FS - - 1 1 Device - LPC11U35 FS - - 1 1 Device - LPC11U36 FS - - 1 1 Device - LPC11U37 FS - - 1 1 Device FS LPC11U37H FS - - 1 1 Device - Cortex-M0+ LPC11U67 FS - - 1 1 Device - LPC11U68 FS - - 1 1 Device LS, FS Support Software CMX-USB Device Stack (by CMX Systems) CMX-USB Host Stack (by CMX Systems) emUSB Device Stack (by SEGGER) EUSBD (Embedded USB Device) Stack (by HCC-Embedded) EUSBH (Embedded USB Host) Stack (by HCC-Embedded) I2S - USB Audio Demo (Oct 19, 2007)   OT-USB USB Device/Host/OTG Stack (by OnChip Technologies) smxUSBD Device Stack (by Micro Digital) smxUSBH Host Stack (by Micro Digital) smxUSBO OTG Software (by Micro Digital) µC/USB Device Stack (by Micrium) µC/USB Host Stack (by Micrium) USB Audio Device Example for LPC214x (by Keil) (Feb 6, 2006) USB Audio Device Example for LPC23xx/LPC24xx (by Keil) (Jun 19, 2007) USB Device Stack (by Thesycon) USB Host Stack (by Thesycon) USB Human Interface Device (HID) Example for LPC214x (by IAR Systems) (Aug 11, 2005) USB Human Interface Device (HID) Example for LPC214x (by Keil) (Feb 6, 2006) USB Human Interface Device (HID) Example for LPC23xx/LPC24xx (by Keil) (Jun 19, 2007) USB Mass Storage Device Example for LPC214x (by Keil) (Feb 6, 2006) USB Mass Storage Device Example for LPC23xx/LPC24xx (by Keil) (Jun 19, 2007)   Windows Embedded CE BSP for NXP LH7A404 (by Adeneo) Windows Embedded CE BSP for NXP LPC3180 (by Adeneo) Windows Embedded CE BSP for NXP LPC32x0 (by Adeneo) Application Notes AN10703 NXP USB host lite V1 (Jul 14, 2008) Articles ARM7 µCs Feature True Full-Speed USB (in Electronic Products) (Aug 2005) Cortex-M0 based MCUs have flexible USB port (in Electronic Products) (Apr 11, 2011) Links     USB Implementers Forum, Inc.
記事全体を表示
Build procedures Open the M0 and M4 projects by clocking on the uvproj files. Make sure the 'iram' version of the project is selected in the target seleciton window. Select the Build target item from the Project menu to build the images. Build the M0 version of the project first, as the M0 binary is used for the M4 version. The FLASH version of the project works the same way as the IRAM version, but runs out of FLASH while using IRAM for RW data. When building the FLASH version, make sure both the M0 and M4 binaries are built using the FLASH configuration. Build the M0 version first, and then the M4 version. The BOOT1 to BOOT4 jumpers on the Hitex board should be setup as BOOT1-1-2, BOOT2-2-3, BOOT3-2-3, and BOOT4-1-2. Opened M0 project shown below Opened M4 project shown below Start the debug session Connect the Keil ULink2 JTAG debugger to the Hitex LPC4350 board's 10-pin JTAG connector. Power up the board by plugging in a 5.0v supply into the power plug (X14). On my board, the boot configuration was set as follows: BOOT1-1-2, BOOT2-2-3, BOOT3-2-3, BOOT4-2-3. Make sure the JTAG is setup correctly for dual-core debugging. In the M4 project window, select the Start/stop Debug Session item from the debug menu to load the image into the board. The image should load and run until the main() function. At this point, you can select run from the debug menu to start the M4 core. The M4 core will initialize the system and board and boot the M0 core. Both the M0 and M4 core will be running FreeRTOS and the red, blue, and green LEDs will start blinking. Let the M4 core run for a few seconds and then select stop from the debug menu. The red LED will stop blinking (indicating the M4 core is stopped), while the blue and green LEDs will continue blinking. After a short time, the green LED will quit blinking and only the blue LED will blink. The green LED is controlled by the shared memory queue the M4 core populates. When the M4 core was stopped, the filling of the queue on the M4 side was stopped, so the M0 core continued processing what was left in the queue until it ran out on entries. Restart the M4 core and both the red and green LEDs will start blinking again. Stop the M4 core and wait until the green LED stops blinking. Leave the M4 core stopped and switch to the M0 project. Select Start/stop Debug Session item from the debug menu to connect to the running process. The M0 core will stop once you do this. Make absolutely sure that the debug options for loading the image into memory or altering system configuration via the linker init file are dsiabled, as we don't want to reload and restart the process that was kicked off from the M4 core. At this point, both the M0 and M4 debug sessions are halted. You can start and stop or single step via each session independently! Select run from the M0 or M4 sessions' debug menu to restart only that core. Depending on which core you've started, the red or blue LED (and possibly green for the M0 core if the queue has data) will start blinking. You can view the state of shared memory queue in real-time by opening a memory window and typing in the address 0x10080000. You'll see the M4 and M0 indexes incrementing.
記事全体を表示
This project explains how to build and deploy u-boot for platforms using the LPC177x_8x devices. To build u-boot, you will need to system running the Linux operating system, that latest CodeSourcery GNU tools for the Linux OS, the u-boot source code, and the u-boot patch(es) for the LPC1788. Feaures implemented -------------------------------------------------------------------------------- Support for the EA1788 board with 32-bit DRAM (32MB) Support for the EA1788 board's NAND FLASH Support for the LPC177x_8x internal FLASH Ethernet support Limited MPU support u-boot known issues -------------------------------------------------------------------------------- Issue: 'reset' command causes the board to crash Workaround: Use 'cmreset' command instead Issue: 'boot' command causes the board to crash Workaround: Use environment variables and scripting with go command instead Issue: bootvx command causes board crash Workaround: None, but there is no reason to use this command Feaures not implemented -------------------------------------------------------------------------------- FLASH 'protect' command and features are not implemented (easily implemented) Interrupt/NVIC support not implemented (easily implemented) Possiible improvements -------------------------------------------------------------------------------- Systick can be used instead of the LPC1788 match timer The relocation code has been 'worked around' and is not implemented correctly A macro file for device spcific IRQs ie needed with weak links to be included in the startup file (arch specific with device overrides) A basic MPU driver is there and seems to work, but could be improved The ethernet driver and PHY setup are 'board specific', but could be moved to the drivers area and the generic PHY support could be used u-boot operational bootup overview -------------------------------------------------------------------------------- Here is an overview of how u-boot boots on the LPC1788. - LPC1788 boot ROM transfer control to u-boot code in internal FLASH at address 0x0 per CM3 bootup procedure - u-boot code first sets up the MPU - Pin muxing, clocking, and DRAM are all initialized - Code and data are relocated from FLASH to DRAM - BSS segment is cleared in DRAM - Control is transferred to u-boot code in DRAM - u-boot board_init_f() is called which does initial u-boot setup - board_init_r() is called for later u-boot setup - u-boot operates normally out of DRAM Location of the ported files -------------------------------------------------------------------------------- arch/arm/cpu/cortex-m3 - Cortex M3 specific files (mpu, startup, etc.) arch/arm/cpu/cortex-m3/lpc1788 - LPC1788 specific files (timer, serial, etc.) arch/arm/include/asm/arch-cortex-m3 - Cortex M3 header files arch/arm/include/asm/arch-lpc17xx - LPC177x_8x specific header files board/nxp - board specific area for board using NXP devices board/nxp/ea1788 - EA1788 board specific files (setup, nand, etc.) include/configs/ea1788.h - EA1788 board specific configuration file
記事全体を表示
Introduction I get asked lots of questions on how to build and deploy the kickstart loader and S1L to a new LPC32x0 based board. This topic will go through the procedure step-by-step for the FDI3250 and the PHY3250 boards on how to build the tools and program them to the board. It will also explain the things you need to change for a new board. The Phytec and FDI boards were chosen for this topic because they differ in the type of DRAM (SDR vs DDR), NAND device page size (small page vs large page), and primary bootloader deployment method (serial vs JTAG). The Embedded Artists board is also available, which provides a serial deployment method with DDR and large page NAND FLASH. To get started, you will need a LPC32x0 based development board, the v2.01 release of the LPC32x0 Common Driver Library (CDL), a JTAG debugger (FDI3250 board), serial cable(s) for the board, and the CodeSourcery Lite GNU toolchain. LPC3250 v2.01 CDL -> attached. CodeSourcery toolchain Future Designs (FDI) LPC3250 based board Phytec LPC3250 based board LPC32x0 bootloaders installation overview The LPC32x0 CDL contains some basic examples, CPU startup code, board startup code for supported boards, basic drivers, bootloaders, and utilities for deploying the bootloaders into NAND FLASH, a serial EEPROM, or via the serial port. These bootloaders somehow need to be installed on the board. For development boards, it's possible to completely reprogram the board regardless of the boot devices state, if UART 5 is connected as the default bootup UART. This allows a tool called the serial loader tool to be used to download and program the boot device without the need for a JTAG debugger. If UART 5 isn't the default boot UART (or is not available at boot time), the boot device needs to be programmed via a JTAG unit or other method. A lot more information related to the LPC32x0 boot process can be found in the LPC32x0 User's guide. More information about the LPC32x0 boot process, the serial loader, and the startup code in the CDL can be found in the bottom of the page. The Phytec board uses UART 5 as the default boot UART and will use the serial loader tool to setup the board's initial bootloader. The serial loader tool only works with UART 5 on the LPC32x0 devices, as UART 5 is the only UART supported for boot up in the LPC32x0's boot ROM. The FDI board uses UART 1 as the default boot UART. Because UART 1 is not used by the boot ROM, it cannot be used with the serial loader tool. Instead, the bootloader software will be deployed to the board with the J-Link Lite LPC Edition JTAG debugger. The J-Link Lite LPC Edition is a low-cost JTAG debugger for LPC devices included with the FDI board. The Future Designs board included a LPC Edition of the J-Link Lite JTAG debugger. This debugger will be initially used to burn the kickstart loader and S1L? into the board's NAND FLASH. To use the debugger, first download the J-Link software from Segger's website at http://www.segger.com/cms/jlink-software.html. Install the software per the documentation and verify that the debugger can communicate with the board. J-link Commander doesn't requires a license to run with the LPC Edtition. Bootloaders and burners The CDL offers several bootloader options and a number of methods for deploying a bootloader to your board. There are several bootloader concepts involved here that are much better explained in the CDL startup code documentation. Burners A burner is an application that resides in the LPC32x0's memory and burns an image in another location into memory into the boot device on the board. The boot device may be NAND FLASH, a serial EEPROM or FLASH, or even NOR FLASH. The CDL contains 2 types of example NAND burner applications - MLC and SLC and burner applications for NOR FLASH (Phytec) and serial FLASH (Phytec). When burning an image to be booted from NAND FLASH, the MLC version must be used for the boot ROM to NAND load step. For all other NAND boot types, the SLC version must be used. Kickstart and Stage 1 applications The kickstart and Stage 1 applications are the common terms used with the LPC32x0 when talking about booting the LPC32x0. A kickstart (loader or bootloader) refers to a simple bootloader that is loaded and booted from the boot ROM which has the primary purpose of loading and booting another image. Any image loaded and booted via the LPC32x0 boot ROM has a size limit of about 54K, or 15.5K if booting from small page NAND FLASH. The kickstart loader always loads into IRAM at address 0x08000000. The kickstart loader usually performs some basic board functions such as initializing DRAM, clocks, GPIOs, etc. If the stage 1 application needed by the kickstart loader needs to be located in DRAM, the kickstart loader must initialize it prior to loading it. A stage 1 applcation is an application that is loaded by the kickstart loader. The stage 1 application can be a Linux kernel, 3rd party bootloader, simple binary, or any other piece of code. The stage 1 application has no size limit and can be loaded anywhere in memory. Example stage 1 applications include u-boot, the CDL examples, the Stage 1 Loader (S1L), or eboot. The S1L application is commonly used as the stage 1 application with available 3rd party development boards, but it isn't needed. It should be noted that the kickstart and stage 1 application concepts don't really apply to the LPC32x0 when booting from NOR FLASH, although a version of the kickstart loader and S1L are available for the NOR FLASH on the Phytec board that maintain the original approach when setting up to boot u-boot from NOR FLASH. Depending on what you need, the best approach may vary. The table below helps explains different approachs to handling the bootloaders and application load. Boot method Best approach Booting an application > 54K with large page NAND FLASH Use a kickstart loader smaller than 54K that configures DRAM and clocking. Kickstart loader loads stage 1 application from NAND into DRAM and starts it. Kickstart loader is in block 0. Stage 1 application is in block 1 and on. Booting an application <= 54K with large page NAND FLASH Application can be stored in NAND block 0. Booting an application > 15.5K with small page NAND FLASH Use a kickstart loader smaller than 15.5K that configures DRAM and clocking. Kickstart loader loads stage 1 application from NAND into DRAM and starts it. Kickstart loader is in block 0. Stage 1 application is in block 1 and on. If the kickstart loader image cannot be built in under 15.5K, move the clock setup into the stage 1 application. Booting an application <= 15.5K with small page NAND FLASH Application can be stored in NAND block 0. Booting from serial EEPROM/FLASH Use a kickstart loader smaller than 54K that configures DRAM and clocking. Kickstart loader loads stage 1 application from the serial EEPROM/FLASH into DRAM and starts it. Kickstart loader is at the start of the EEPROM/FLASH. Stage 1 application isafter kickstart loader. Booting from NOR FLASH NOR FLASH can be directly executed from and doesn't require pre-loading, so the kickstart/stage 1 application concepts don't apply. Booting from the serial port The image must always be 54K or less and loads into IRAM at address 0x08000000. Using burners to place bootloaders into the boot device The burners are applications that simply burn another image into the boot device for the board. The CDL breaks up the burners into a kickstart burner and a stage 1 application burner. The kickstart burner places the kickstart application as per the table below. Kickstart burner - NAND Places kickstart loader into block 0 of NAND using the MLC NAND controller. Sets up the necessary boot information (ICR) for NAND boot the boot ROM needs. Kickstart burner - SPI EEPROM/FLASH Places kickstart loader into the start of a serial EEPROM/FLASH. Sets up the necessary boot information for SPI boot the boot ROM needs. Kickstart burner - NOR Burns a NOR verison of the kickstart loader into the start of NOR FLASH. Only needed if the conceptual kickstart/stage 1 application approach is used with NOR FLASH. The stage 1 application burner places the stage 1 application as per the table below. Stage 1 application - NAND Places stage 1 application into block 1 and on of NAND FLASH using the SLC NAND controller. Note that in all NXP applications, the MLC controller is currently only used for the boot ROM. Stage 1 application - SPI EEPROM/FLASH Places the stage 1 application into the the serial EEPROM/FLASH after the kickstart loader. Stage 1 application - NOR Places the stage 1 application into the the NOR FLASH after the kickstart loader. Only needed if the conceptual kickstart/stage 1 application approach is used with NOR FLASH. As an example, to burn the kickstart loader into NAND FLASH, the kickstart burner must be loaded first. Once it has been loaded, the kickstart loader is loaded into a different location in memory. The kickstart burner then initializes NAND FLASH and burns the kickstart loader into block 0. The kickstart burner varies slightly in how it works with JTAG and serial loader methods. For the JTAG method, the kickstart burner and loader must be loaded as 2 different programs. For the serial loader mthod, the burner application loads the loader via the serial port via the serial loader tool. The serial loader method is the preferred method, but may not be optimal for production systems. The entire process of burning the kickstart loader and stage 1 application has been covered before in the CDL bootloader topics. Once you have working verisons of the kickstart and stage 1 application burners, the kickstart loader, and the stage 1 application (S1L will be used in the examples following), you can use the Restoring the FDI3250 boot loaders  for the FDI board and the Restoring the PHY3250 boot loaders  for the Phytec board to get the images into the boards. Is S1L needed? S1L is an application usually loaded from the kickstart loader that allows other applications to be booted frmo SD cards, serial port, or NAND FLASH. It's also a very good tool for bringing up and testing new boards based on the LCP32x0. If you are developing a new LPC32x0 based board, the test functions built into S1L can be useful for testing DRAM and helping to locate possible DRAM configuration issues. If you are using or testing multiple operating systems (ie, WinCE and Linux), S1L can boot the u-boot and eboot loaders without alter NAND FLASH. The build procedure below assumes S1L will also be built and deployed. Building the burners, kickstart loader, and S1L Make sure you have the CodeSourcery Lite GNU tools installed and that you can run them from a CMD shell in Windows. Download and install the LPC32x0 v2.01 CDL and navigate to the 'software' directory in a CMD shell window. If you are usnig the Phytec board, type 'setenv phy3250 gnu 1' to setup the build system for the Phytec board. FDI board developers should use 'setenv fdi3250 gnu 1'. See below for the Phytec setup. You need to build 4 programs - the kickstart burner, S1L burner, kickstart loader, and S1L (from kick full) application. To build the programs, type 'make' in the following directories in the CDL. For the Phytec board, .\software\csps\lpc32xx\bsps\phy3250\startup\examples\Burners\nand_sb\kickstart (Kickstart burner for small page FLASH) .\software\csps\lpc32xx\bsps\phy3250\startup\examples\Burners\nand_sb\s1lapp (stage 1 application burner for small page FLASH) .\software\csps\lpc32xx\bsps\phy3250\startup\examples\kickstart\kickstart_sb_nand (Kickstart loader for small page FLASH) .\software\csps\lpc32xx\bsps\phy3250\startup\examples\s1l\s1l_from_kick_full (S1L for small page FLASH) You should get 4 images as follows:    * burner_kickstart_nand_small_block_gnu.bin (kickstart burner)    * burner_s1app_nand_small_block_gnu.bin (stage 1 application burner)    * kickstart_nand_small_block_gnu.bin (kickstart loader)    * s1l_from_kick_gnu.bin (S1L (stage 1 application)) For the FDI board, .\software\csps\lpc32xx\bsps\fdi3250\startup\examples\Burners\nand_lb\kickstart_jtag (Kickstart burner for large page FLASH) .\software\csps\lpc32xx\bsps\fdi3250\startup\examples\Burners\nand_lb\s1lapp_jtag (stage 1 application burner for large page FLASH) .\software\csps\lpc32xx\bsps\fdi3250\startup\examples\kickstart\kickstart_lb_nand (Kickstart loader for large page FLASH) .\software\csps\lpc32xx\bsps\fdi3250\startup\examples\s1l\s1l_from_kick(S1L for large page FLASH) You should get 4 images as follows:    * burner_kickstart_nand_large_block_jtag_gnu.elf (kickstart burner)    * burner_s1app_nand_large_block_jtag_gnu.elf (stage 1 application burner)    * kickstart_nand_large_block_gnu.bin (kickstart loader)    * s1l_from_kick_gnu.bin (S1L (stage 1 application)) Note that for the FDI board, there are elf files and bin files. The elf files are the burner applicaitons loaded via the JTAG debugger while the binaries are the payload applications to be used by the burner program (to be burned into NAND FLASH). See the FDI JTAG burn procedure for the FDI board and the Phytec serial loader burn procedure for the Phytec board for information on how to use these images. Modifying the CDL/BSP for a new target board The burners, kickstart loader, and S1L can all be fairly easily to another board. In most cases, the porting process requires grabbing an existing BSP as a reference, modifying compile time defines for the board specific changes, and changing a little bit of existing code to support the new board. As most of the code is common to the burners, kickstart loader, and S1L - a change in one place usually applies to everything in the BSP. The easiest place to start is to copy an existing BSP which has the supported features closest to the new board renaming the BSP to something else. The table below shows the current board BSPs in the CDL and the default support they provide. The BSps are located in the .\software\csps\lpc32xx\bsps\ directory. phy3250 (Phytec board) Supports 64MB single data rate (SDR) SDRAM (32-bit configuration only), small page NAND FLASH, and UART 5 as the default boot UART, serial loader tool is used to burn images into the board fdi3250 (FDI board) Supports 32MB double data rate (DDR) SDRAM , large page NAND FLASH, and UART 1 as the default boot UART, JTAG must be used to burn images into the board ea3250 (Embedded Artists board) Supports 64MB double data rate (DDR) SDRAM , large page NAND FLASH, and UART 5 as the default boot UART, serial loader tool is used to burn images into the board Example: If I was developing a new LPC3250 based board that uses 64MB DDR memory, large page FLASH, and has UART 2 as the default UART port, I would make a copy of the fdi3250 BSP in the CDL's bsps directory, maybe renaming it to 'myboard3250'. If possible always start with an existing known working board BSP instead of using the generic BSP. From the example above, the 'myboard3250'BSP will be used as the new target board for the example. The myboard3250 board has the following differences over the FDI3250 board.    * Uses 64MB of DDR instead of 32MB    * Uses 512MB of large page NAND FLASH instead of 256MB What the new board will do The new myboard3250 design will be used for running the Linux operating system. The system will boot from NAND FLASH and should boot into u-boot as soon as possible. As this is a new board, S1L can be used to temporarily setup and provide early board testing before deploying u-boot. S1L can either be permanently/temporarily setup as the application to boot from the kickstart loader or can be directly loaded from the serial port. We'll go through each option below. Optional 1: Loading S1L directly via the serial port S1L can be directly loaded into IRAM and executed via the serial port - if it's less than 54K in size. If you don't want to make a customer version of the tools for an S1L based configuration, but still want to do some initial DRAM and NAND testing with S1L before trying u-boot, building the IRAM version of S1L is the way to go. The Optional 2: Using S1L to load and run u-boot The currently supported development boards use the kickstart loader to load and run S1L. S1L in turn loads and runs u-boot. S1L runs inside of IRAM. This option is typical of current development boards. End use case for the bootloaders Ideally, we would like to have the LPC32x0 boot ROM boot directly into u-boot. Because u-boot is greater than 64MB and resides in SDRAM, we need to use the kickstart loader to initially boot the board from NAND block 0 (into IRAM) and then chain load the u-boot loader into SDRAM from NAND block 1. This requires a kickstart burner application, a burner for u-boot (u-boot is the stage 1 application in this case), and a kickstart loader that loads the stage 1 application (u-boot) in SDRAM. Although this seems like the best place to start for a new board, it might be easier to start with S1L with either option 1 or 2. S1L has some built-in utilities for testing and helping to determine DRAM related issues. BSP configurable items for startup code For the v2.01 release of the CDL, some of the items that can be changed for the BSP include NAND timing and geometry, SDRAM type and timing, supported UARTs, locations of where the stage 1 application is stored in NAND FLASH and loaded in memory, and more. A complete list of items can be found in the CDL startup code documentation. The code typically also requires a few code changes to work correctly on new boards. DRAM modifcations Setting up DRAM requires no new code - only the defines for DRAM timing and geometry we inherited from the copied code need to be modified to support the new board's devices. Locate the dram_configs.h file in the BSP and open it. Each define has a comment associated with it. Selecting the right values for these defines will allow the generic DRAM configuration code to properly configure the SDRAM. For the new board, I made the following change. If the part on the new board had different timing requirements, RAS/CAS latencies, a different mode word layout, or other differences, I would have to change a lot more. /* Number of rows, columns, and bank bits for the SDRAM device */ #define SDRAM_BANK_BITS 2 /* 2 bits = 4 banks, 1 bit = 2 banks */ //#define SDRAM_COLS 9 // Deleted this line #define SDRAM_COLS 10 // Added this line #define SDRAM_ROWS 13 #endif NAND driver modifcations part 1 The copied BSP already includes large page NAND FLASH drivers for the SLC and MLC. Several small changes need to be added to make these drivers work for the new board. NAND timing values need to be setup for the MLC and SLC controllers. These timings, in clocks based on the HCLK rate, need to be configured specifically for the NAND device and selected system clock rates. Once these are correctly setup, all of the applications that use NAND support will use these timing values. The values are shown below. /* Timing setup for the NAND MLC controller timing registers. These    values can be adjusted to optimize the program time using the    burner software with NAND. If your not worried about how long it    takes to program your kickstart loader (or if your not using a    kickstart loader), don't worry about changing these values. If you    need to burn the kickstart, this can be speeded up by tweaking    these values. See the 32x0 user's guide for info on these    values. These should be programmed to work with the selected bus    (HCLK) speed - because the burn image is usually small (under 54K),    there really is not reason to change these values. */ #define MLC_TCEA_TIME   0x3 #define MLC_TWBTRB_TIME 0xF #define MLC_TRHZ_TIME   0x3 #define MLC_TREH_TIME   0x7 #define MLC_TRP_TIME    0x7 #define MLC_TWH_TIME    0x7 #define MLC_TWP_TIME    0x7 /* Timing setup for the NAND SLC controller timing registers. On    systems using NAND, these values effect how fast the kickstart    loader loads the stage 1 application or how fast the S1L    application handles NAND operations. See the 32x0 user's guide for    info on these values. These should be programmed to work with the    selected bus (HCLK) speed. */ #define SLC_NAND_W_RDY    14 #define SLC_NAND_W_WIDTH  0x5 #define SLC_NAND_W_HOLD   0x2 #define SLC_NAND_W_SETUP  0x1 #define SLC_NAND_R_RDY    14 #define SLC_NAND_R_WIDTH  0x4 #define SLC_NAND_R_HOLD   0x2 #define SLC_NAND_R_SETUP  0x1 For the myboard3250 board, the NAND timings are unchanged. NAND driver modifcations part 2 Each NAND device has a specific geometry associated with it used to setup access the device's blocks, pages, etc. This geometry needs to be supplied for each board.  To setup this geometry, edit the board_mlc_nand_lb_driver.c and board_slc_nand_lb_driver.c files init() functions. If you only support one device, you can directly setup the values for the nandgeom structure based on the device's values. The original code inherited for this board checked several different NAND ID's and picked a geometry based on that configuration. For the myboard3250 board, only 1 configuration as shown below is supported. nandgeom.num_blocks      = 8192; nandgeom.pages_per_block = 64; nandgeom.data_bytes_per_page = 2048; nandgeom.spare_bytes_per_page = 64; nandgeom.address_cycles = 5; Changing the CPU clock speed The default CPU clock speed, bus (HCLK) speed, and peripheral (PCLK) speed can be setup in the setup.h file by altering the values shown below. The values - 266MHz CPU clock, 133MHz bus clock, 13.325MHz PCLK - are unchanged from the copied clock rates. /* CPU speed in Hz */ #define CPU_CLOCK_RATE 266000000 /* HCLK bus divider rate - this can be 1, 2 or 4 and defines the HCLK   bus rate in relation to the CPU speed. This can never exceed   133MHz. DDR systems only work with a value of 2 or 4. */ #define HCLK_DIVIDER 2 /* PCLK divider rate - this can be 1 to 32 and defines PCLK bus rate    in relation to CPU speed. This value should be picked to allow the    PCLK to run as close as possible to 13MHz. Slightly exceeding 13Mhz    is ok */ #define PCLK_DIVIDER 20 Modifying GPIO states and pin muxing GPIO states and pin muxing can usually be delayed until the main application starts. If any changes need to be made to pin muxing or GPIO states that should be done as soon as possible after boot, they can be made in the gpio_setup.c file. No changes will be made for this new board. Default UART selection The default UART used in S1L, kickstart, and the burner applications can be setup in the misc_config.h file. The FDI board uses UART1 as shown below. Only UART5 will work with the serial loader. Setting anything other than UART5 will allow UART output to occur as normal otherwise on that UART. /* UART device and rate, supported UART devices are UART3, UART4,    UART5, and UART6 */ #define UARTOUTPUTDEV UART1 #define UARTOUTPUTRATE 115200 #define UART_IS_HIGHSPEED Setting load addresses for the burner applications and kickstart loader The burner applications need to know where to load an image to be burnt into the boot device at some location in memory. Likewise, the kickstart loader needs to know where the stage 1 application needs to be loaded into memory. The addresses and sizes for the loader are specified in the misc_config.h file. The defaults are unchanged since S1L plans on being used. #define BURNER_LOAD_ADDR 0x8000 #define BURNER_LOAD_SIZE    (54*1024) #define STAGE1_LOAD_ADDR 0x8000  /* Load at address 0x8000 */ #define STAGE1_LOAD_SIZE 0x20000 /* Load 128k */ The above values say that the burner applications (kickstart and stage 1 app burners) will load their image to be burned into NAND FLASH at address 0x8000 with size 54K and 128K, respectively. S1L is built to run at address 0x8000 and fits in under 128K. If I build the kickstart and S1L burners, the kicstart laoder, and S1L with these settings, the load addresses will be as follows:    * Kickstart and S1L burners load the image to burn into the boot device at address 0x00008000    * Kickstart loader loads and runs at adress 0x00000000 (will always run at address 0x00000000 unless built for NOR FLASH)    * S1L loads and runs at address 0x00008000. This is where the kickstart loader loads and places S1L. 128K will always be loaded regardless of the actual size if S1L stored in NAND by the stage 1 application burner. Making a configuration for u-boot without S1L If I wanted to make a bootloader configuration with the burners to have the kickstart loader directly load and run u-boot instead of S1L, I would make the following changes: #define BURNER_LOAD_ADDR 0x80000000 #define BURNER_LOAD_SIZE    (54*1024) #define STAGE1_LOAD_ADDR 0x81F8000  /* Load at address 0x81F80000 */ #define STAGE1_LOAD_SIZE 0x40000 /* Load 256k */ Once I rebuild the burners and the kickstart loader (S1L isn't used, so it isn't built), I can use the kickstart burner with the kickstart loader and the stage 1 application burner with the u-boot.bin file. u-boot for the FDI board is normally built to load and run at address 0x81F80000. With the above changes, the following is done instead:    * Kickstart and S1L burners load the image to burn into the boot device at address 0x80000000 (larger DRAM area, won't fit in IRAM)    * Kickstart loader loads and runs at adress 0x00000000 (these values have nothing to do with the kickstart loader address)    * Kickstart loader loads stage 1 application (u-boot) into address 0x81F80000. The load size is 256K regardless if u-boot is actually smaller. S1L configuration changes If you do use S1L, look at the settings in the s1l_cfg.h file. The settings in this file are used to set the default S1L prompt string, S1L startup message, and the S1L NAND application storage area (used with the nsave, nload commands). Wrapup The CDL startup code documentation covers the startup code and it's various configurations very well. If possible, use a known working BSP in the CDL to start with when developing a new BSP for you board. The upcoming v2.02 release of the LCP32x0 CDL will have improved common code layout with no more board specific DRAM and NAND code, which should help a lot with porting the startup code to new boards.
記事全体を表示
NXP Semiconductors and OnChip Technologies have partnered to provide USBHostLite software for our LPC1000, LPC2000, and LPC3000 families of microcontrollers with USB host capability. These include members of the LPC17xx series, the LPC23xx series, the LPC24xx series, the LPC29xx series, the LPC31xx series, and the LPC32xx series of microcontrollers. USBHostLite is a stripped-down USB host stack that includes only USB mass storage class support with the bare minimum code to run in an OS-less environment. USBHostLite provides a simple solution for accessing the files on USB mass storage devices such as USB Pen Drives, USB Hard Disk Drives, etc., connected to the USB Host port. Features The USBHostLite supports the following features: Runs without any operating system Contains small memory footprint Source code is written in ANSI C and is independent of IDE Supports control and bulk transfers Supports FAT16 file system Simple File APIs allow file read and write operations Well structured and easily understandable source code Limitations The complimentary USBHostLite software from NXP has following limitations: USBHostLite is currently only ported to and tested on Embedded Artists' LPC2468 OEM board and Keil's MCB1760 board. Classes other than the mass storage are not supported. The mass storage interface must be present in the first configuration. Max Logical Unit Number (LUN) greater than zero not supported. File systems other than FAT16 are not supported. Long filenames are not supported. Files located in folders other than root directory cannot be accesed. The buffer size used in the application must not exceed 4KB. Note: This application note describes the USBHostLite stack in general and its application on the Embedded Artists LPC2468 OEM board in particular. Software USBHostLite for LPC source code is free to NXP customers for unlimited use with NXP LPC2000 and LPC3000 families of microcontrollers only. By downloading or using the USBHostLite software, you agree to use it solely with these NXP microcontrollers.USBHostLite stack ported to the LPC293x devices on the Hitex LPC2939 board: USBHostLite for LPC293x VBeta 0.01 (Jul 28, 2009) - Attached USBHostLite stack ported to the LPC2468 device on the Embedded Artists LPC2468 OEM board: USBHostLite for LPC23xx/LPC24xx V1.00 (Jan 4, 2010) USBHostLite stack ported to the LPC1768 device on the Keil MCB1760 evaluation board: USBHostLite for LPC17xx VBeta 0.01 (Jul 14, 2009) - Attached For customer applications requiring full featured and production quality embedded USB stacks, OnChip Technologies LLC provides embedded USB Host/Device/OTG stacks that are fully compliant with the USB specifications and offers great degree of stability and configurability. More Information Disclaimer This software is provided AS-IS by NXP Semiconductors. NXP Semiconductors does not support or warrant the software contained herein for any purpose other than for informational use. Please contact OnChip Technologies LLC for further assistance including support options and other embedded USB host/device/OTG stacks. For Further Assistance OnChip Technologies LLC Other Professional USB Host Stack Solutions for the LPC3000, LPC2000, and LPC1000 families CMX Systems CMX-USB Host HCC Embedded USB (EUSB) HostLite Stack Micrium μC/USB Host Micro Digital smxUSBH Quadros RTXCusb Software Thesycon Embedded USB Host Stack
記事全体を表示
Description This example implements a HID class host mode device that enumerates a HID class device with keyboard report descriptors and displays key press characters on a terminal. NOTE: many keyboards enumerate as a HUB device which is not supported by this example. Compiler build configurations The software that makes up this example is designed to run on many different development boards. Therefore the compiler must be configured to build an image that is targeted to the development board you are using. This section explains how to set these build configurations for each of the supported compilers.   LPCXpresso IDE Configure projects   right click on the BSP project in the project explorer window   click Build Configurations->Set Active->(see configuration in table below)   repeat these steps with the CDL, nxpUSBlib, and Example_KeyboardHost Configure MCU   right click on the Example_KeyboardHost project in the project explorer window   click Properties->C/C++ Build->MCU settings->(see configuration in table below) Configure the indexer    click Window->Preferences->C/C++->Indexer->Use active build configuration   BSP CDL nxpUSBlib Example_KeyboardDevice MCU LPC1850  / Hitex LPC18xx_HITEX LPC18xx LPC18xx_Host LPC18xx LPC1850 LPC4330  / Xplorer LPC4330_Xplorer LPC18xx LPC18xx_Host LPC18xx LPC4330 LPC4350  / Element14 LPC1435_ELEMENT14 LPC18xx LPC18xx_Host LPC18xx LPC4350 LPC1768  / MCB1700 LPC1768_MCB1700 LPC17xx LPC17xx_Host LPC17xx LPC1768 LPC1768  / LPCXpresso LPC17xx_LPCXpressoRevB LPC17xx LPC17xx_Host LPC17xx LPC1768 NOTE: The LPC18xx CDL is used with boards that hold LPC43xx parts. This is done because the LPC43xx CDL is currently experimental. The LPC18xx USB library is used because both parts share the same controller. Keil uVision 4 IDE Configure a Batch Build     click on Project->Batch Build...   expand the BSP project to display a list of project targets   select the project target by checking the appropriate checkbox (see target list in table below)   repeat these steps with the CDL, nxpUSBlib_Host, and Example_KeyboardDevice BSP CDL nxpUSBlib_Host Example_KeyboardDevice LPC1850  / Hitex HITEX1800 LPC18xx LPC18xx_Host HITEX1800 LPC1768  / MCB1700 MCB1700 LPC17xx LPC17xx_Host MCB1700   Board connections and configurations LPC18xx_HITEX (LPC1850 Hitex Evaluation Board)  older A2 design schematic ./BSP/schematics/HITEX_SCM_LPC1850EVA-A2-2.pdf Connect the JTAG to the 20 pin receptacle marked X4 JTAG Connect a keyboard into the type A receptacle marked X10 Connect a 9-pin serial cable into the receptacle marked UART X1. Connect the other end of this cable into a PC running a terminal program. To power the board:   Connect the type-B end of a powered USB cable into the receptacle marked X13   or   Supply 5v to the DC connector labeled X14   LPC18xx_HITEX (LPC1850 Hitex Evaluation Board)  newer A3 design schematic ./BSP/schematics/HITEX_Final_LPC1850EVA-A3.pdf   LPC1768_MCB1700 (Keil MCB1700 development board) schematic: ./BSP/schematics/mcb1700-schematics.pdf Jumper Setting   E/U 1-2 UMODE 1-2 D- Host D+ Host VBUS 1-2 VDDIO 1-2 VDDREG 1-2 ISP removed Connect the JTAG debugger to the 20 pin JTAG or 10 pin Cortex Debug connector Connect a 9 pin serial cable between COM0 on the board and a PC running a terminal program. Baud rate = 9600 Plug a keyboard into the type A receptacle marked HOST To power the board:   Connect the type-B end of a powered USB cable to the type-B receptacle labeled 'Device'   or   Supply 5v to the -VIN+ pins between the JTAG and COM0 receptacles Once the board is powered the following LEDs should be illuminated:     Power     100MHz     USC   LPC17xx_LPCXpressoRevB (LPCXpresso LPC17xx on the LPCXpresso Rev B base board) schematic: ./BSP/schematics/LPCXpressoLPC1769revB.pdf   Plug the LPCXpresso LPC1769 board into the connector labeled J4 on a   LPCXpresso base board Connect the JTAG to the mini USB receptacle labeled J3 on the LPCXpresso LPC1769   board Configure the base board according to the users guide from Embedded Artists Install jumpers 1-2, 3-4, 5-6 on the jumper block marked J61 on the base board Plug a keyboard into the type A receptacle marked J60 on the base board Connect the mini type-B end of a USB cable to the USB-to-serial receptacle on   the base board labeled X3 and the type-A end to the USB receptacle on a PC. Once the USB cable is connected to the board the following LEDs should be   illuminated:     LED25  (vbus)     LED26  (3.3v rail)          PC configuration Use a PC running Windows XP, Vista or 7 to display runtime diagnostics that can be viewed with a terminal emulation program like Teraterm or Hyperterm. The baud rate in these programs should be set to 9600.   Build and debug the example LPCXpresso IDE In the project explorer window of the IDE right click on the Example_KeyboardHost project and select Debug As->C/C++ MCU Application In the main window of the IDE click Run->Resume to start running the application   Keil uVision 4 IDE In the Batch Build window, select the project targets as described in Compiler Build Configurations and then click Build In the main window of the IDE click Debug->Start/Stop Debug Session click Debug->Run   How this example runs and what to look for When the example is first run the terminal window will display: Keyboard Host Demo running.   When the keyboard is plugged in the terminal window will display: Device Attached. Keyboard Enumerated.   When a key is pressed on the keyboard an upper case character corresponding to that key will be displayed in the terminal window.   When the keyboard is unplugged the ternimal window will display: Device Unattached.
記事全体を表示
Introduction Adding IOH functionality to a custom project is not difficult, but does involve a few important steps. These steps are explained in more detail on this page. Since the implementation of most of the steps are IDE dependant, details for each supported IDE (LPCXpresso, Keil MDK, IAR EWARM) are given on seperate pages.   Steps in general In general, the following steps should be followed when using an IOH library in a custom project: 1. Add the IOH library (*.lib, *.a) to the project. 2. Add the path where the library's header file resides to the project’s include path. 3. #include the IOH header file in the source code of the application. 4. Configure the linker to place the IOH related sections in the IOH SRAM using our provided linker scripts (for LPCXpresso this step is performed automatically when an IOH enabled device is selected). 5. Enable the IOH SRAM (SRAM1) before C-library initialization (startup/system_init code). 6. Interact with IOH via the library's API.   Detailed instructions per IDE For more detailed, per IDE instructions, visit the pages below: LPCXpresso Keil MDK IAR EWARM
記事全体を表示
Description This example implements a mass storage class host mode device that enumerates a mass storage class device (USB flash drive). It reads the first sector of the device and displays a hexdump style listing of that data on a terminal.   Compiler build configurations The software that makes up this example is designed to run on many different development boards. Therefore the compiler must be configured to build an image that is targeted to the development board you are using. This section explains how to set these build configurations for each of the supported compilers.   LPCXpresso IDE Configure projects   right click on the BSP project in the project explorer window   click Build Configurations->Set Active->(see configuration in table below)   repeat these steps with the CDL, nxpUSBlib, and Example_MassStorageHost Configure MCU   right click on the Example_MassStorageHost project in the project explorer window   click Properties->C/C++ Build->MCU settings->(see configuration in table below) Configure the indexer    click Window->Preferences->C/C++->Indexer->Use active build configuration   BSP CDL nxpUSBlib Example_MassStorageDevice MCU LPC1850  / Hitex LPC18xx_HITEX LPC18xx LPC18xx_Host LPC18xx LPC1850 LPC4330  / Xplorer LPC4330_Xplorer LPC18xx LPC18xx_Host LPC18xx LPC4330 LPC4350  / Element14 LPC1435_ELEMENT14 LPC18xx LPC18xx_Host LPC18xx LPC4350 LPC1768  / MCB1700 LPC1768_MCB1700 LPC17xx LPC17xx_Host LPC17xx LPC1768 LPC1768  / LPCXpresso LPC17xx_LPCXpressoRevB LPC17xx LPC17xx_Host LPC17xx LPC1768 NOTE: The LPC18xx CDL is used with boards that hold LPC43xx parts. This is done because the LPC43xx CDL is currently experimental. The LPC18xx USB library is used because both parts share the same controller. Keil uVision 4 IDE Configure a Batch Build     click on Project->Batch Build...   expand the BSP project to display a list of project targets   select the project target by checking the appropriate checkbox (see target list in table below)   repeat these steps with the CDL, nxpUSBlib_Host, and Example_MassStorageDevice BSP CDL nxpUSBlib_Host Example_MassStorageDevice LPC1850  / Hitex HITEX1800 LPC18xx LPC18xx_Host HITEX1800 LPC1768  / MCB1700 MCB1700 LPC17xx LPC17xx_Host MCB1700   Board connections and configurations LPC18xx_HITEX (LPC1850 Hitex Evaluation Board)  older A2 design schematic ./BSP/schematics/HITEX_SCM_LPC1850EVA-A2-2.pdf Connect the JTAG to the 20 pin receptacle marked X4 JTAG Connect a USB flash drive into the type A receptacle marked X10 Connect a 9-pin serial cable into the receptacle marked UART X1. Connect the other end of this cable into a PC running a terminal program. To power the board:   Connect the type-B end of a powered USB cable into the receptacle marked X13   or   Supply 5v to the DC connector labeled X14   LPC18xx_HITEX (LPC1850 Hitex Evaluation Board)  newer A3 design schematic ./BSP/schematics/HITEX_Final_LPC1850EVA-A3.pdf   LPC1768_MCB1700 (Keil MCB1700 development board) schematic: ./BSP/schematics/mcb1700-schematics.pdf Jumper Setting   E/U 1-2 UMODE 1-2 D- Host D+ Host VBUS 1-2 VDDIO 1-2 VDDREG 1-2 ISP removed Connect the JTAG debugger to the 20 pin JTAG or 10 pin Cortex Debug connector Connect a 9 pin serial cable between COM0 on the board and a PC running a terminal program. Baud rate = 9600 Plug a USB flash drive into the type A receptacle marked HOST To power the board:   Connect the type-B end of a powered USB cable to the type-B receptacle labeled 'Device'   or   Supply 5v to the -VIN+ pins between the JTAG and COM0 receptacles Once the board is powered the following LEDs should be illuminated:     Power     100MHz     USC   LPC17xx_LPCXpressoRevB (LPCXpresso LPC17xx on the LPCXpresso Rev B base board) schematic: ./BSP/schematics/LPCXpressoLPC1769revB.pdf   Plug the LPCXpresso LPC1769 board into the connector labeled J4 on a   LPCXpresso base board Connect the JTAG to the mini USB receptacle labeled J3 on the LPCXpresso LPC1769   board Configure the base board according to the users guide from Embedded Artists Install jumpers 1-2, 3-4, 5-6 on the jumper block marked J61 on the base board Plug a USB flash drive into the type A receptacle marked J60 on the base board Connect the mini type-B end of a USB cable to the USB-to-serial receptacle on   the base board labeled X3 and the type-A end to the USB receptacle on a PC. Once the USB cable is connected to the board the following LEDs should be   illuminated:     LED25  (vbus)     LED26  (3.3v rail)          PC configuration Use a PC running Windows XP, Vista or 7 to display runtime diagnostics that can be viewed with a terminal emulation program like Teraterm or Hyperterm. The baud rate in these programs should be set to 9600.   Build and debug the example LPCXpresso IDE In the project explorer window of the IDE right click on the Example_MassStorageHost project and select Debug As->C/C++ MCU Application In the main window of the IDE click Run->Resume to start running the application   Keil uVision 4 IDE In the Batch Build window, select the project targets as described in Compiler Build Configurations and then click Build In the main window of the IDE click Debug->Start/Stop Debug Session click Debug->Run   How this example runs and what to look for When the example is first run the terminal window will display: Mass Storage Host Demo running.   When a flash drive is plugged in the terminal window will display   something similar to this:   Device Attached.   Total LUNs: 1 - Using first LUN in device. Vendor "USB     ", Product "Flash Disk      " Mass Storage Device Enumerated.   Waiting until ready...   Retrieving Capacity...   1957887 blocks of 512 bytes.   Contents of first block:   33 C0 8E D0 BC 00 7C FB 50 07 50 1F FC BE 1B 7C     3.....|.P.P....| BF 1B 06 50 57 B9 E5 01 F3 A4 CB BD BE 07 B1 04     ...PW........... 38 6E 00 7C 09 75 13 83 C5 10 E2 F4 CD 18 8B F5     8n.|.u.......... 83 C6 10 49 74 19 38 2C 74 F6 A0 B5 07 B4 07 8B     ...It.8,t....... F0 AC 3C 00 74 FC BB 07 00 B4 0E CD 10 EB F2 88     ..<.t........... 4E 10 E8 46 00 73 2A FE 46 10 80 7E 04 0B 74 0B     N..F.s*.F..~..t. 80 7E 04 0C 74 05 A0 B6 07 75 D2 80 46 02 06 83     .~..t....u..F... 46 08 06 83 56 0A 00 E8 21 00 73 05 A0 B6 07 EB     F...V...!.s..... BC 81 3E FE 7D 55 AA 74 0B 80 7E 10 00 74 C8 A0     ..>.}U.t..~..t.. B7 07 EB A9 8B FC 1E 57 8B F5 CB BF 05 00 8A 56     .......W.......V 00 B4 08 CD 13 72 23 8A C1 24 3F 98 8A DE 8A FC     .....r#..$?..... 43 F7 E3 8B D1 86 D6 B1 06 D2 EE 42 F7 E2 39 56     C..........B..9V 0A 77 23 72 05 39 46 08 73 1C B8 01 02 BB 00 7C     .w#r.9F.s......| 8B 4E 02 8B 56 00 CD 13 73 51 4F 74 4E 32 E4 8A     .N..V...sQOtN2.. 56 00 CD 13 EB E4 8A 56 00 60 BB AA 55 B4 41 CD     V......V.`..U.A. 13 72 36 81 FB 55 AA 75 30 F6 C1 01 74 2B 61 60     .r6..U.u0...t+a` 6A 00 6A 00 FF 76 0A FF 76 08 6A 00 68 00 7C 6A     j.j..v..v.j.h.|j 01 6A 10 B4 42 8B F4 CD 13 61 61 73 0E 4F 74 0B     .j..B....aas.Ot. 32 E4 8A 56 00 CD 13 EB D6 61 F9 C3 49 6E 76 61     2..V.....a..Inva 6C 69 64 20 70 61 72 74 69 74 69 6F 6E 20 74 61     lid partition ta 62 6C 65 00 45 72 72 6F 72 20 6C 6F 61 64 69 6E     ble.Error loadin 67 20 6F 70 65 72 61 74 69 6E 67 20 73 79 73 74     g operating syst 65 6D 00 4D 69 73 73 69 6E 67 20 6F 70 65 72 61     em.Missing opera 74 69 6E 67 20 73 79 73 74 65 6D 00 00 00 00 00     ting system..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ................ 00 00 00 00 00 2C 44 63 18 2E 07 C3 00 00 80 01     .....,Dc........ 01 00 06 20 00 77 00 02 00 00 00 DE 1D 00 00 00     ... .w.......... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA     ..............U.   When the flash drive is unplugged the ternimal window will display: Device Unattached.
記事全体を表示
Introduction There are several options for Software Encryption running on the different LPC ARM microcontrollers. Some of these options are offered for free from NXP, while others are free open-source solutions and still others are royalty-based encryption offerings from 3rd parties. These different solutions offer trade-offs between costs, memory footprint, performance and support levels, so please choose the library that best meets the needs of your project. Links Application Note: AES encryption and decryption software on LPC MCUs (zip file) Cypherbridge Systems: uSSL and CDK Real Time Logic: SharkSSL Library Real Time Logic: ARM Cortex-M0 Benchmarks Security Innovation: Encryption Libraries for LPC2000 ARM7 LPC1200 Bootloader from Metratec Polar SSL Open-Source Encryption Library Cya SSL Open-Source Encryption Library "All other trademarks, product names, trade names, and logos used within these pages are the property of their respective holders."
記事全体を表示
If you plan on using NAND FLASH for booting your system, the recommendation is to use the MLC NAND controller for initially booting a small 'kickstart' image from block 0, and then using the loaded kickstart image to boot and load a full image from blocks 1 and on using the NAND SLC controller. The kickstart image cannot exceed 56K bytes in size on a large page FLASH device or 15.5K bytes in size on a small page device. A question often asked is "Why isn't the MLC NAND controller just used for everything?". The MLC NAND controller has stronger ECC support, but is limited on data layout. The minimum transfer size when using ECC is 528 bytes. Because of this 528 bytes transfer size, the ECC is also computed on the non-payload data area. Operating systems that use the spare area in NAND FLASH (such as the Linux MTD OOB area) will not be able to actively alter just the spare area without erasing and altering the entire block. This means that items such as bad block markers, JFFS2 clean markers, or block leveling data can't be stored outside the main page data's ECC algorithm. Because of this, the MLC controller can't readily be used for normal data operations.
記事全体を表示
The LPC18xx/43xx DFUSec utility referred to in this article should NOT be used. It has been replaced by LPCScrypt. Use of LCT will result in a very old firmware version, which will contain bugs and not support some features in MCUXpresso IDE and 3rd party tools. This information is supplied for reference only. What does this tool do? The LPC18xx/43xx DFUSec utility is a Windows PC tool that provides support functions for LPC18xx/43xx microcontroller via USB. The tool is composed of 3 components: the Image Programmer, the LPC-Link 2 Configuration Tool, and the Security Support Tool (v2.00). This tool has been called the LPC18xx/43xx DFU Utility (DFUUtil) or DFUSec in versions prior to v1.10. DFUSec is the common name for the tool that covers all these components, For instructions on how to use a specific capability of the DFUSec tool, use the menu on the right.   Where to download and download pre-requisites Update: DFUSec and the LPC-Link 2 Configuration Tool are the same tool. Download DFUSec from the LCT link below and enable 'DFUSEC' mode by unchecking the Link2 lock button on the LCT file menu. As of v2.00 of the LCT, you no longer need to manually install .NET or the driver package - the installer will do that for you if it already isn't installed. WinUSB only needs to be installed on Windows XP machines - it is already part of Win 7/8. All you need to do is download and install the LCT. Before you can use DFUSec, you'll need to install WINUSB and the Microsoft.NET framework 4. DFUSec is available in pre-configured packages for the Image Programmer, Link Configuration Tool (LCT), and the (upcoming) Security Tool. (files attached)   Image Programmer The Image Programmer uses the USB DFU boot capability of the LPC18xx/43xx devices to program the internal FLASH or EEPROM, or the SPIFLASH on some boards. To do this, a small USB image is first downloaded to the board via USB using DFU and then it communicates with the PC application. To use the Image Programmer, the a USB port must be connected for USB boot with the LPC18xx/43xx device. Most commercial boards - such as boards from Embedded Artists, Hitex, Keil, and NGX - provide this support. The Image Programmer provides the following capabilities: In circuit programming and re-programming of internal FLASH and internal EEPROM on all LPC18xx/43xx devices via USB In circuit programming and re-programming of some SPIFLASH devices available on LPC18xx/43xx boards Smiple DFU download and execution of an image in IRAM with optional automated download whenever a board is plugged in Optional checksum generation at program time Boot header generation (needed by SPIFLASH or DFU boot) Sequenced program operations for complex image layouts across multiple storage (internal FLASH, internal EEPROM, SPIFLASH) types - a single session can quickly program all storage with a single automated USB sessions Extendable FLASH support - add support for other storage devices in the programming algorithm firmware LPC-Link 2 Configuration tool The LPC-Link 2 Configuration Tool is used to load firmware images onto the LPC-Link-2 board ir LPCXpresso V2 boards with the integrated LPC-Link 2 (LINK DFU) interface. This allows loading a firmware image that supports debugging via USB such as JLINK or CMSIS-DAP for development environments other than the LPCXpresso-IDE. To use the tool, select an image for a support LPC-Link 2 boards and follow the in-page instructions. Security Support Tool (upcoming) The Security Support Tool will be available with the DFUSec v2.00 release. This component of DFUSec adds the following capabilities: AES key management - key and vector generation, programming, and (limited) key retrieval Encrypted image generation with support for CMAC header Boot mode locking - disable JTAG, USB, or other capabilities for production systems Ability to encrypt FLASH binaries from Image Programmer to allow re-programming a secure board (if not locked)
記事全体を表示
1.      Important Notes     1.    Please read the build section of Libraries and Example before building anything     2.    Never give batch build with all the items selected.     3.    When building an example make sure the M0 image is built and ready before building the M4 image     4.    Read the latest release notes before proceeding with this document 2.      Introduction This document will provide the instructions and information required to use the LPC43xx dual core demos. The source files can be either obtained from the git server or can be downloaded attached as a compressed zip file. 2.1     Dual Core in LPC43XX The LPC43xx is an ARM M4/M0 based dual core microcontroller. The SoC comes with Internal IRAM/Flash of various sizes. Please read the LPC43xx user manual and the board user manual carefully before starting to use the dual core demos on any of the LPC43XX board. 2.2     Hardware requirements Keil MCB4300 Development board Serial cable or USB to serial port dongle Keil uLink-2 or Keil uLink-Pro or Segger J-Link debugger (for ARM Cortex M devices) Development PC/Laptop (Host Machine) Keil uVision IDE MDK-ARM tool-chain (version 4.54 or above) Terminal emulation software (Teraterm recommended) Windows OS in which Keil tool can run (Windows 7 recommended) 2.3     Software requirements 3.      Directory Structure The software has two main directories, the “library” directory and the “applications” directory. It follows the same directory structure as followed by the “NXPUSBLibrary”. Inside the “applications” directory is the main Keil multi project workspace LPC43xx_Demo_Examples.uvmpw could be found as shown in Figure 1: Directory structure of LPC43xx Dual Core Demo Examples. The library directory has the following libraries[1] in it CDL (for LPC43XX) BSP (for KEIL MCB4357 board) nxpUSBLib (for Host and Device) FreeRTOS IPComm The example directory will have both the nxpUSBlib, and the MultiCore examples. This document will only have the details about the MultiCore examples. The Following MultiCore examples can be found under examples directory. Common (Not an example in itself but is used by all the examples) USB_KBD_HostBlinky) USB_MS_Device (USB Mass Storage device and Blinky) 4.      Libraries 4.1     Building Library Open the Keil uVision multiple project workspace by double clicking on the “LPC43xx_Demo_Examples.uvmpw”. The project workspace opens in the uVision IDE, as shown in Figure 2: LPC43xx_Demo_Example in Keil uVision Workspace. For building the libraries it is recommended to use the batch build option provided by Keil. Select “Project” from the menu (on top of the IDE), followed by “Batch build…”, which will open the batch build window as shown in Figure 3: Batch build dialog. To build a specific library all the other selections must be cleared, this can be done by clicking on “Deselect All” button located in the left side of the dialog. Now to build, say CDL library, the appropriate library configurations must be selected [Example, for CDL “LPC43xx_M4 and LPC43xx_M0” must be selected]. Clicking the build button located at the top left side of the dialog will build the selected library. Each project is provided with a README.TXT file that will help the user to know more about the various configurations and how to use them. The library can also be built configuration by configuration. To do so, one must first make that project active by right clicking on the library and selecting the “Set as Active Project” from the menu that pops up (marked red in Figure 4: Setting active Project and Configuration), now select a configuration from the pull down menu (marked as green in Figure 4: Setting active Project and Configuration). Once the active configuration is selected press “F7” key to start the build process of the active configuration. After successful build select the next configuration and start the build process. 4.2     CDL (Common Driver Library) 4.2.1     Description The common driver library (CDL) will have the functions with which can be used to initialize and operate on any peripheral present in the SoC. It has files that implements functions for each peripheral (lpc43xx_uart, lpc43xx_i2c etc,). The CDL also has the CMSIS sources which will have the startup code required for starting up of the SoC. The CMSIS library has 2 startup files (lpc43xx_startup.S and lpc43xx_startup_m0.S) for Cortex M4 core and Cortex M0 core respectively. 4.2.2     Configurations The CDL supports two configurations (LPC43xx_M4 and LPC43xx_M0) one for each core 4.2.2.1     LPC43xx_M0 This configuration will build the library that could be linked and used with application that is meant to run on M0 core. This library will have the startup code for M0 core. If the users want to develop a new module they must keep in mind that all the IRQ handler names are prefixed with “M0_”. 4.2.2.2     LPC43xx_M4 This configuration will build CDL library, so that it can be linked and used by applications that are compiled for M4 core. 4.2.3     Output Files All output files (including the object and list files) will be located under “keil_ouput” directory of the corresponding library/example CDL_LPC43xx_M4.lib – Generated by building CDL for “LPC43xx_M4” configuration CDL_LPC43xx_M4.lib – Generated by building CDL for “LPC43xx_M0” configuration 4.3     BSP (Board Support Package) Library 4.3.1     Description This library has the functions required to initialize the board specific features. For example the external Flash, external DRAM, pin mux, LEDs etc. This library implements the bsp_init API that initializes the board (Recommended to call only from M4 core). This library supports two boards HITEX LPC4350 and KEIL MCB4357. The user must build the configurations only for the relevant board. Say, for example the users of HITEX 4350 board must build only HITEX4350_M0 and HITEX4350_M4, and should not build anything else. The board configuration that was build last (M0 and M4) will be considered for linking with any application. 4.3.2     Configurations For batch building of this library it is recommended to build only two configurations (M0, M4) that belongs to the same board. 4.3.2.1     MCB4300_M0 This configuration will build the BSP library for MCB4300 board and will provide functions that can be called from M0 core. This configuration must be built only along with MCB4300_M4 and not with any other configuration. 4.3.2.2     MCB4300_M4 This configuration will build the BSP library for MCB4300 board and will provide functions that can be called from M4 core. This configuration must be built only along with MCB4300_M0 and not with any other configuration. 4.3.3     Output Files BSP_LPC43XX_M4.lib – Library generated by building MCB4300_M4 configuration BSP_LPC43XX_M0.lib – Library generated by building MCB4300_M0 configuration Since we do not generate separate libraries for each board the configuration build recently will be taken for linking with the example applications. 4.4     nxpUSBlib (NXP’s USB Library) 4.4.1     Description This library provides the USB host/device support for LPC USB based microcontrollers. The original source of this library can be found at www.lpcware.com. But it is recommended to use the sources provided along with the dual core examples (Has some bug fixes and routines required for dual core operation of this library). For more information refer to document that comes along with the library. 4.4.2     Configurations For batch building this library it is recommended to select all the configurations. LPC43xx_Host_M0 – Configuration that builds USB host stack for M0 core LPC43xx_Device_M0 – Configuration that builds USB device stack for M0 core LPC43xx_Host_M4 – Configuration that builds USB host stack for M4 core LPC43xx_Device_M4 – Configuration that builds USB device stack for M4 core 4.4.3     Output Files nxpUSBlib_LPC43xx_Host_M0.lib – Created by building this library for configuration LPC43xx_Host_M0 nxpUSBlib_LPC43xx_Device_M0.lib – Created by building this library for configuration LPC43xx_Device_M0 nxpUSBlib_LPC43xx_Host_M4.lib – Created by building this library for configuration LPC43xx_Host_M4 nxpUSBlib_LPC43xx_Device_M4.lib – Created by building this library for configuration LPC43xx_Device_M4 4.5     FreeRTOS 4.5.1     Description This library is compiled of the FreeRTOS source obtained from www.freertos.org. Minimal modifications had been made to the OS files so that they will work on LPC43xx in both the cores. For more information about FreeRTOS refer www.freeRTOS.org 4.5.2     Configuration For batch building it is recommended to select all the configurations. 4.5.2.1     LPC43xx_M0 This configuration will compile FreeRTOS library from the sources that could be run from M0 core of LPC43xx. When this configuration is selected the FreeRTOS source will read its configuration header from lpc43xx_m0_FreeRTOSConfig.h kept under config directory of the FreeRTOS library, and will use RITIMER hardware to generate the system ticks. 4.5.2.2     LPC43xx_M4 This configuration will compile FreeRTOS library from the sources that could be run from M4 core of LPC43xx. When this configuration is selected the FreeRTOS source will read its configuration header from lpc43xx_m4_FreeRTOSConfig.h kept under config directory of the FreeRTOS library. 4.5.2.3     Output Files FreeRTOS_LPC43XX_M0.lib – Generated by building the library using LPC43xx_M0 configuration. FreeRTOS_LPC43XX_M4.lib – Generated by building the library using LPC43xx_M4 configuration. 4.6     IPComm (Inter Processor Communication Library) 4.6.1     Description This library provides the functions to communicate between cores (M0/M4). This is required for the applications running on both the cores. For more information about this library and usage refer Application Note AN11177: Inter Processor Communications. 4.6.2     Configuration It is recommended to select all the configuration during the batch build. Standalone_M0 – Building IPC library for this configuration will generate IPC functions without support from any OS and can run on M0 core Standalone_M4 – Building IPC library for this configuration will generate IPC functions without support from any OS and can run on M4 core FreeRTOS_M0 – Building IPC library for this configuration will generate IPC functions with FreeRTOS support and can run on M0 core FreeRTOS_M4 – Building IPC library for this configuration will generate IPC functions with FreeRTOS support and can run on M4 core 4.6.3     Output Files The following are the output files generated for the above configurations respectively IPC_noOS_M0.lib IPC_noOS_M4.lib IPC_FreeRTOS_M0.lib IPC_FreeRTOS_M4.lib 5.      Examples 5.1     Setting up of board and debuggers This section provides information about setting up of various board to execute the dual core examples. For now the examples support only HITEX4350 and MCB4300 boards. 5.1.1     Setting up MCB4300 board Follow the steps below to setup the KEIL MCB4300 board to run the dual core examples Connect the U-Link/J-Link debugger’s 10-Pin debug port header to J6 port of the board. Connect the debugger to the Host PC using USB cable provided with the debugger (Debugger’s power LED should be lit after connecting) Connect a Serial cable (Straight cable) to the board’s P11 (UART0/3) port and connect the other end to the host PC Open teraterm select the COM port corresponding to the Serial Port to which the board is connected, select 115200 as the baud rate and no flow control Connect the USB cable’s[2] (Type-A to Micro-B) Micro-B end to the board’s Micro-B receptacle P2 (USB0) [Not to P4 USB1] Connect the Type-A end of the USB cable to the host PC (now the board should power ON) 5.1.2     Setting up Examples for debugging The following steps must be executed for all the examples. It must only be carried out for M4 targets and need not have to be done for any M0 target. It is applicable only for the examples and not for the libraries. Select the example as active project by right clicking on it (Circled red in Figure 4: Setting active Project and Configuration) Select the M4 configuration from the configuration selection pull down menu (Circled green in Figure 4: Setting active Project and Configuration) In the project view (Located in the left side of the IDE), expand the active example by clicking on it and click on the configuration (shown with a folder icon) Press “Alt” key and while holding it Press and release “F7” key, this will show the options dialog for the currently selected M4 configuration 6.     Now configure your debugger as shown in the figure (Red circles in Figure 5: Debugger configuration in Keil uVision)5.     Click on the “Debug” tab located on the top of the dialog (Blue circle in Figure 5: Debugger configuration in Keil uVision) Click on the Settings button (Green circle in Figure 5: Debugger configuration in Keil uVision) to open the debugger hardware configuration dialog as shown in Figure 7: U-Link debugger Hardware settings Setup the configuration[3] (shown in red circles) in the dialog as shown in Figure 6: U-Link debugger Hardware settings Click OK to save the configuration and close the dialog                                                10.  Now click on the utilities tab at the top of the options dialog (Tab next to the blue circled debug tab in Figure 5: Debugger configuration in Keil uVision) Now the window will look as shown in Figure 7: Keil flash configuration utility window Setup the configuration (red circled) in the utility window as shown in Figure 7: Keil flash configuration utility window Click the settings button (Green circled in Figure 7: Keil flash configuration utility window) That will open the Flash driver setup window as shown in Figure 8 Select the configuration (Red circled) as shown in                                                         Click on the add button (Green Circled in Figure 8: Flash driver configuration window) That will open the flash programming algorithm select window as in Figure 9: Flash Programming Algorighm select window In the flash programming algorithm window select SST39VF3201x[4] and click “Add” button in Figure 9: Flash Programming Algorighm select window Repeat Step 16 to 18 for LPC18xx/43xx IAP 512kB for both 1A000000 and 1B000000 address range Click OK (Blue circled) as shown in Figure 8: Flash driver configuration window Press OK in Keil flash configuration utility window to save the configuration and exit the options window Repeat the steps for all the examples for all the M4 configurations                                                               5.1.3     Building & Executing Examples Every example will have a set of M0 configuration and M4 configurations, the user must build the M0 configuration first and then the corresponding M4 configuration. For compatible configurations please refer to the configuration table provided under each example. Once both M0 and the corresponding M4 images are built click on the debug button   to start the debugging. Press “F5” key to execute the code. 5.2     Blinky Example 5.2.1     Description This example blinks the LED1 (Red LED in HITEX board) and LED2 (Green LED in HITEX board). The M4 core pushes the LED1 turn ON/OFF message at an interval of every 500 milliseconds and the message is popped by M0 core and based on the message it turn ON/OFF LED1. The same way M0 core pushes LED2 ON/OFF message and is popped by the M4 core and blinks the LED2 accordingly. So, on both the cores there will be two tasks running one pushes the message another pops and executes the command present in the message. 5.2.2     Configuration M4 Configuration M0 Configuration Remarks Standalone_M4 Standalone_M0 FreeRTOS_M0 All configurations possible FreeRTOS_M4 Standalone_M0 FreeRTOS_M0 All configurations possible Table 5‑1: Blinky Example configuration 5.2.3     Expected Output LED1 and LED2 blinks at different rates. 5.3     USB Host Stack Example (with Keyboard class driver) Description This example runs the USB Host stack in any of the core with the keyboard class driver. The stack running in any core will receive the keystroke and will push it to the other core via message queue. The other core will receive the message and print the key pressed to UART. It then sends an acknowledgement message to theblinky task running along with the USB host stack to toggle an LED. 5.3.1     Configuration M4 Configuration M0 Configuration USB_noOS_M4 Blinky_noOS_M0 Blinky_FreeRTOS_M0 USB_FreeRTOS_M4 Blinky_noOS_M0 Blinky_FreeRTOS_M0 Blinky_FreeRTOS_M4 USB_noOS_M0 USB_FreeRTOS_M0 Blinky_noOS_M4 USB_noOS_M0 USB_FreeRTOS_M0 Table 5‑3: USB Keyboard demo configurations 5.3.2     Expected Output Blinks LED1 and LED2, connecting the keyboard to the host port will print the message keyboard enumerated on the COM port. Any key pressed in the keyboard will be printed on the teraterm. Key press will also toggle LED3. 5.4     USB Device Stack Example (Mass Storage Device Class) 5.4.1     Description This example will run the USB device stack (Mass storage class) in any core while running the Blinky on both the cores. This example also has the FAT file system parser for getting the data present in the file storage area. 5.4.2     Configuration Same as USB Keyboard demo configurations 5.4.3     Expected Output The Host PC will enumerate the board as a USB disk and will contain a README.TXT that carries the text “USB Device demonstration”. LED1 and LED2 will be blinked by the Blinky tasks. The Mass Storage task will toggle the LED3 for every SCSI command it receives.
記事全体を表示
This procedure no longer applies to DFUSec/LCT. As of v2.00 of the LCT, you no longer need to manually install .NET or the WinUSB driver package - the LCT installer will do that for you if it already isn't installed. WinUSB only needs to be installed on Windows XP machines - it is already part of Win 7/8. All you need to do is download and install the LCT. To install the WinUSB drivers for the LPC18xx/43xx boards, first configure the board for USB boot. Plug in the USB connector to the board (add external power to the board if necessary) and a new USB device (LPC) should appear. Download the drivers at http://www.lpcware.com/content/nxpfile/lpc18xx43xx-winusb-drivers-dfu-boot Un-compress the drivers and point the driver installation dialog to the INF file in the uncompressed package. After installation is complete, you should have a new device available for the LPC18xx or LPC43x.
記事全体を表示
LPC177x_8x memory requirements The LPC177x_8x device family is available with varying amounts of internal FLASH and IRAM. Depending on the device you select, the amount of FLASH available is bwteen 64KBytes and 256KBytes. Internal IRAM varies from 16KBytes to 64KBytes. All the devices also have peripheral RAM which can vary between 8KBytes to 32KByytes. Internal IRAM cannot be used for ethernet buffers (or any DMA buffers). Peripheral RAM can be used for ethernet buffers and/or CPU buffers. On the minimum device configuration, a chip will contain 64K of FLASH, 32K of internal IRAM, and 8K of peripheral RAM. In this minimum configuration, this amounts up to 64KBytes for code, 32KBytes maximum for CPU data, and 8KBytes for ethernet buffers. When using external memory such as DRAM, ethernet buffers can be located in external memory ande have no size limitations. For the tcpecho example included with the LCP LWIP release, the memory sizes for different configurations are shown in the table below. These are not absolutely minimum buildable sizes and have extra buffers to prevent packet drops due to run-time memory allocation. All of these projects are built with the Keil toolchain at the -O3 optimization level. LWIP_DEBUG is not enabled. Note these images support DHCP, UDP, and broadcast. Project description Notes Linker output tcpecho, FLASH (standalone) Stack_Size      EQU     0x00001000 Heap_Size       EQU     0x00000000 #define LPC_NUM_BUFF_RXDESCS 4 #define LPC_NUM_BUFF_TXDESCS 4 #define PBUF_POOL_SIZE                  4 #define MEM_SIZE                        16384     Total RO  Size (Code + RO Data)                33772 (  32.98kB)     Total RW  Size (RW Data + ZI Data)             34560 (  33.75kB)     Total ROM Size (Code + RO Data + RW Data)      34016 (  33.22kB) tcpecho, FLASH (FreeRTOS)* Stack_Size      EQU     0x00001000 Heap_Size       EQU     0x00000000 #define LPC_NUM_BUFF_RXDESCS 3 #define LPC_NUM_BUFF_TXDESCS 3 #define PBUF_POOL_SIZE                  6 #define MEM_SIZE                        (12*1024)     Total RO  Size (Code + RO Data)                43800 (  42.77kB)     Total RW  Size (RW Data + ZI Data)             67208 (  65.63kB)     Total ROM Size (Code + RO Data + RW Data)      43848 (  42.82kB) *FreeRTOS build also includes extra heap and stack space used by FreeRTOS and additional LWIP libraries and support for use with an RTOS. Note these sizes may vary for many reasons including compiler/linker versions, selected build options, etc. The sizes are meant as a guideline for memory usage only. LPC177x_8x memory requirements at the minimum system configuration To get the minimum configuration for a build, the DHCP support, UDP support, and broadcast support is disabled and the build is setup with a static IP address.  The LWIP raw API is used with an RTOS. The table below shows configuration options and build size information. Debug is disabled and the -O3 optimization level is used with the Keil tools. Project description Notes Linker output tcpecho, FLASH (minimal, standalone) Stack_Size      EQU     0x00000800 Heap_Size       EQU     0x00000000 #define LPC_NUM_BUFF_RXDESCS 3 #define LPC_NUM_BUFF_TXDESCS 2 #define PBUF_POOL_SIZE                  4 #define MEM_SIZE                        8192     Total RO  Size (Code + RO Data)                33724 (  32.93kB)     Total RW  Size (RW Data + ZI Data)             24260 (  23.69kB)     Total ROM Size (Code + RO Data + RW Data)      33968 (  33.17kB) LPC18xx/43xx memory requirements The LPC18xx/43xx device family is available with varying amounts of IRAM. For the tcpecho example included with the LCP LWIP release, the memory sizes for different configurations are shown in the table below. These are not absolutely minimum buildable sizes and have extra buffers to prevent packet drops due to run-time memory allocation. All of these projects are built with the Keil toolchain at the -O3 optimization level. LWIP_DEBUG is not enabled. Note these images support DHCP, UDP, and broadcast. Project description Notes Linker output tcpecho, FLASH (standalone) Stack_Size      EQU     0x00001000 Heap_Size       EQU     0x00000400# define LPC_NUM_BUFF_RXDESCS 20 #define LPC_NUM_BUFF_TXDESCS 20 #define PBUF_POOL_SIZE                  64 #define MEM_SIZE                        (64*1024)     Total RO  Size (Code + RO Data)                36432 (  35.58kB)     Total RW  Size (RW Data + ZI Data)            177016 ( 172.87kB)     Total ROM Size (Code + RO Data + RW Data)      36708 (  35.85kB) tcpecho, FLASH (FreeRTOS)* Stack_Size      EQU     0x00001000 Heap_Size       EQU     0x00008000 #define LPC_NUM_BUFF_RXDESCS 20 #define LPC_NUM_BUFF_TXDESCS 20 #define PBUF_POOL_SIZE                  48 #define MEM_SIZE                        (64*1024)     Total RO  Size (Code + RO Data)                46744 (  45.65kB)     Total RW  Size (RW Data + ZI Data)            186172 ( 181.81kB)     Total ROM Size (Code + RO Data + RW Data)      46792 (  45.70kB) *FreeRTOS build also includes extra heap and stack space used by FreeRTOS and additional LWIP libraries and support for use with an RTOS. Note these sizes may vary for many reasons including compiler/linker versions, selected build options, etc. The sizes are meant as a guideline for memory usage only. LPC18xx/43xx memory requirements at the minimum system configuration To get the minimum configuration for a build, the DHCP support, UDP support, and broadcast support is disabled and the build is setup with a static IP address.  The LWIP raw API is used without an RTOS. The table below shows configuration options and build size information. Debug is disabled and the -O3 optimization level is used with the Keil tools. Project description Notes Linker output tcpecho, FLASH (minimal, standalone) Stack_Size      EQU     0x00000800 Heap_Size       EQU     0x00000000 #define LPC_NUM_BUFF_RXDESCS 3 #define LPC_NUM_BUFF_TXDESCS 2 #define PBUF_POOL_SIZE                  8 #define MEM_SIZE                        (12*1024)     Total RO  Size (Code + RO Data)                36396 (  35.54kB)     Total RW  Size (RW Data + ZI Data)             34656 (  33.84kB)     Total ROM Size (Code + RO Data + RW Data)      36672 (  35.81kB)
記事全体を表示
This procedure explains how to install and update u-boot on the EA1788 board. The install procedure requires 'Flash Magic' to place the initial image in internal FLASH, but once the image is in FLASH, it can be updated via u-boot itself. 1)Get the Flash Magic software at http://www.flashmagictool.com/ and install it. 2)Connect the serial UART on the EA1788 board to your Windows PC with the installed Flash Magic software. 3)On the EA1788 board, hold down the SW6 button while resetting the board to put it in ISP mode. 4)Download the program (u-boot-lpc.hex) via Flash Magic (see configuration below). It takes about 3 minutes to download. 5)Close Flash Magic and open a terminal program )ie, Teraterm) and configure it for 115.2K8N1 on the EA1788's connected UART. 6)Reset the board and you should get the UART prompt. U-Boot 2011.06 (Aug 16 2011 - 16:47:50) NXP LPC1788 Cortex-M3 DRAM:  32 MiB Flash: 512 KiB NAND:  128 MiB Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 In:    serial Out:   serial Err:   serial uboot> 7)To update u-boot, download the u-boot-lpc.bin program via serial port or network and update with the procedure below. The procedure below uses tftp. Err:   serial uboot> dhcp BOOTP broadcast 1 DHCP client bound to address 10.1.10.14 TFTP from server 10.1.10.15; our IP address is 10.1.10.14 Filename 'u-boot-lpc.bin'. Load address: 0xa0100000 Loading: ######################### done Bytes transferred = 125580 (1ea8c hex) uboot> erase bank 1 Erase Flash Bank # 1 Erasing 30 sectors starting at sector  0. uboot> cp.b 0xa0100000 0x0 0x1f000 Copy to Flash... Writing 126976 bytes from a0100000 from 0, please be patient... done uboot> cmreset resetting ... U-Boot 2011.06 (Aug 16 2011 - 15:38:33) NXP LPC1788 Cortex-M3 DRAM:  32 MiB Flash: 512 KiB NAND:  128 MiB Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 In:    serial Out:   serial Err:   serial uboot>
記事全体を表示