LPCware Archive Content

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPCware Archive Content

Discussions

Sort by:
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
View full article
Before you can use the MLC extractor tool (MET), you need to customize it for your hardware and rebuild it. You will need the CodeSourcery GNU toolchain (EABI version) to build the files. Download the CodeSourcery toolchain from here. A free 'lite' version is available that can be used to build the MET. Install the tools and make sure the PATH environment variable for the tools is setup correctly. MET relies on the Common Driver Library (CDL) for some of it's functions, so the LPC32x0 CDL (v2.11 and later) must be downloaded and installed first. You can download the CDL from here. Once the CDL is downloaded, install it by extracting the directory somewhere on your Windows XP/Vista/7 machine. Download the MET file from this page and extract the contents into the CDL directory from the step above. The file must specifically be extracted in the ./csps/lpc32x0/bsps/common/examples directory. The most likely change needed to the source code is adding a specific NAND device to the NAND detection list. In the mlc_fgen_tool folder in the ./csps/lpc32x0/bsps/common/examples directory, edit the nandif.c file and locate the sys_nand_ids structure. This structure contains a list of recognized NAND IDs with geometry for each ID. This list is self-explanatory - either edit an existing entry in the list or add a new entry in the list with the new NAND information. <code>   /* ST MICRO Flash */   {     LPCNAND_VENDOR_STMICRO,     0x73, /* Device ID */     512, /* Page size */     32, /* Pages per block */     1024, /* Total blocks */     {SLCNAND_DEFAULT_TIMING, MLCNAND_DEFAULT_TIMING},/* Timing */   } <code> You can rebuild the code with the steps below. First, open a Windows 'cmd' shell and switch to the CDL directory. Use the "setenv" command to setup the environment for build. Note the 2nd parameter (board) doesn't matter, so we'll use "ohy3250". The 3rd parameter is the toolchain which will be ""gnu". The 4rth parameter is "1", indicating verbose output. Switch to the mlc_fgen_tool directory and type "make". If the tools are installed and everything is setup correctly, the tool will build and you will get a "mlcextractor.bin" file that can be used with the serial loader tool.
View full article
Introduction Electric motors drive motion in all kinds of applications, from washing machines and exercise treadmills to the HVAC (heating, ventilation, and air conditioning) systems in commercial buildings. The drawback is that they can consume quite a bit of energy. Refrigeration for homes and offices accounts for nearly 10% of the world's energy usage, and roughly 60% of all the electrical power generated in the US is consumed by electric motors. Designers are using 32-bit MCUs to add sophisticated motor control to their systems, and thereby improving efficiency, reducing cost, and saving energy. In consumer appliances, for example, the trend is away from motors that cycle on and off (and require high starting torque) and more toward smaller, electrically-controlled motors that operate continuously, at a slower speed, and adapt their torque (and speed) to maintain the desired performance. These new, electrically-controlled motors save power and, as an added bonus, reduce maintenance and extend service life because they use fewer mechanical components. NXP Advantage Design challenges for electric motors include finding ways to improve accuracy, increase speed, reduce power consumption, limit electromagnetic interference (EMI), lower cost, and expand the number of tasks the system can perform. NXP's 32-bit ARM MCUs meet all of these challenges. They offer ample performance with integrated options specially tailored to motor control: NXP Product Families for Motor Control All the ARM MCUs integrate general-purpose PWMs for basic motor control. Five families offer dedicated motor-control PWMs (LPC43xx, LPC18xx, LPC17xx, LPC32x0, LPC29xx). Four families offer a Quadrature Encoder Interface (QEI) for very accurate orientation, feedback, and control (LPC43xx, LPC18xx, LPC17xx, LPC29xx). Four families offer 6-channel PWMs for control of three-phase motors (LPC21xx, LPC22xx, LPC23xx, LPC24xx). Two families offer the proprietary State Configurable Timer (SCT) subsystem, which is comprised of a timer array with a state machine enabling complex functionality including event-controlled PWM waveform generation, ADC synchronization, and dead time control. This timer subsystem gives embedded designers increased flexibility to create user-defined waveforms and control signals (LPC43xx, LPC18xx). Many of today's motor-control applications use 8- or 16-bit MCUs or DSPs. Designers looking to upgrade to 32-bit performance will find plenty of choices in NXP's portfolio. Our MCUs offer a range of motor-control options, in a wide variety of formats: Package sizes from 48 to 320 pins Memories from 8KB to 1MB of flash, with flashless options Clocks from 1kHz to 267MHz DSP capabilities with the LPC4300 Cortex-M4 series Integrated ADCs in 10- and 12-bit formats Built-in peripherals, including Ethernet, USB, LCD, and CAN Products Comparison Table Below, are NXP's ARM MCUs featuring dedicated PWMs for motor control and Quadrature Encoder Interfaces (QEIs): Product(s) ARM Core Motor Control PWM (# Channels) Quadrature Encoder Interface State Configurable Timer LPC43xx Cortex-M4 9 X X LPC18xx Cortex-M3 9 X X LPC17xx Cortex-M3 6 X LPC32x0 ARM926EJ 9 LPC29xx ARM968E-S 24 X Cortex-M3-Based MCUs with Dedicated Motor Control PWMs Click here for more information: ARM Cortex-M3 Core MCUs ARM9-Based MCUs with Dedicated Motor Control PWMs Click here for more information: ARM9 Core MCUs Support LPCXpresso Motor Control Kit The LPCXpresso Motor Control Kit, developed in partnership with Embedded Artists, is ideal for prototyping your motor control project or when you wish to learn more about motor control. The board can be directly controlled by LPCXpresso LPC1114/LPC1343/LPC1768 target boards. With this universal platform, it is possible to control BLDC, BLAC, stepper, and dual-brushed DC motors. The kit comes with the LPCXpresso Motor Control Board, an LPCXpresso LPC1114 target board with LPC-Link JTAG (supported by the LPCXpresso IDE), a BLDC motor with hall sensors, and a 24V/60W power supply. The kit is available through NXP's distribution network. Embedded Artists LPCXpresso Motor Control Kit Multimedia Presentation Software Sample Code Bundle for LPC213x/LPC214x Peripherals using ARM's RealView (Mar 8, 2006) Sample Code Bundle for LPC213x/LPC214x Peripherals using Keil's μVision (Dec 18, 2008) Sample Code Bundle for LPC23xx/LPC24xx Peripherals using Keil's μVision V1.60 (Mar 10, 2009) TN0700x Sample Code V1.00 (Jun 22, 2007)   More Information   Links Microcontrollers USB Support   Disclaimer Software from NXP referenced on this page 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.
View full article
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.
View full article
This section explains the LPC32x0 boot process for the various non-volatile memory types or the UART. Depending on the boot device, there may be limitations to the boot image size. This limitation may prevent a desired image from initially loading and executing – instead requiring a smaller boot loader to be loaded first and then using it to load and run a more capable boot loader or application. LPC32x0 boot options The LPC32x0 supports booting from small and large block NAND FLASH, SPI EEPROMS or FLASH, NOR FLASH, and via the UART. In production systems, the UART boot method isn't used. However, the UART boot method serves a useful purpose in early board debug, The boot order for the LPC32x0 is as follows: UART, SPI, NOR, NAND. UART boot can be disabled to reduce boot time. Each boot device will be tried prior to the next device. A device is bootable if the boot ROM locates a special boot pattern that identifies the device as bootable. It's possible that a system can have SPI FLASH, NOR FLASH, and NAND FLASH and only boot from NAND FLASH although the SPI and NOR methods are attempted first. (For example, the Phytec 3250 board has all 3 of these boot devices, but normally boots from NAND FLASH). When the LPC32x0 chip is reset, the internal boot ROM is executed. It queries each device looking for a special boot pattern used to identify the device as bootable. The first device that returns a correct pattern will be used by the boot ROM as the bootable device. The boot ROM will then either copy data from the bootable device (NAND and SPI FLASH) or transfer control to the bootable device (NOR FLASH). Each boot method is explained in the following sections. See the LPC32x0 User's guide for more information on the LPC32x0 boot process. UART boot The UART boot option allows a binary to be downloaded into the board and then executed prior to any code running in NAND, SPI, or NOR FLASH. This is useful for burning new images into FLASH, testing simple applications, or recovering the board from corrupt boot code. UART boot is used with the burner tools in the CDL package to program the bootloader(s) into the boot device. UART5 is supported with the UART boot option, so new designs should make UART5 available for debugging. For a system that entirely runs from IRAM, this allows a system to download an image via the UART that provides interactive access once the image is executed. The downloaded interactive program can be used for bandwidth or memory tests, register dumps, further image loading, or other functions. Initial versions of S1L can be used with this boot method to test different SDRAM configurations using the included SDRAM initialization code. Using this approach, startup and debug of the SDRAM code (one of the tougher issues of bringing up a new board) can be drastically simplified. NOR FLASH boot On a system that boots from NOR FLASH, the ARM core directly executes code from the NOR FLASH device starting at address 0xE0000004. The first 4 bytes at address 0xE0000000 are used for the special boot pattern value required by the boot ROM to identify the device as bootable and to provide the boot width (8, 16, or 32 bits). SPI FLASH/EEPROM boot On a system that boots from SPI, a small image is copied from the SPI EEPROM or FLASH device at offset 0x8 into IRAM at address 0x00000000. The first 4 bytes are used for the special boot pattern value required by the boot ROM. The next 4 bytes are used to designate the size of the image to load at offset 0x8 in the SPI device. After the image is loaded into IRAM, control is transferred to address 0x00000000. The maximum image boot size that can be loaded with this method is 54K. NAND FLASH boot On a system that boots from NAND FLASH, a small image is copied from block 0 or block 1 of the NAND device into IRAM at address 0x00000000. The maximum bootable image size for NAND FLASH boot is 54K, or 1 block minus 1 page, whichever is smaller. The first page of the boot block is used to store boot information, such as the boot image size and values needed by the boot ROM used for the boot sequence. For small block NAND (32 pages per block and 512 bytes per page) with the first page of the block dedicated to the boot ROM boot information, the maximum boot size is 31 pages of 512 bytes per page, or 15.5K. For large block NAND (64 pages of 2Kbytes per page), the maximum boot size is 54Kbytes. The boot ROM always uses the MLC NAND controller for NAND boot. This requires the boot image booted from NAND by the boot ROM to be programmed into NAND with the MLC NAND controller or with the ECC algorithms required by the MLC NAND controller.
View full article
The Embedded Artists LPC3250 based board ships with the kickstart loader and Stage 1 Loader (S1L) pre-installed to execute from large block NAND FLASH. The kickstart loader resides in NAND block 0 and is loaded into IRAM with the LPC32x0 boot ROM on chip reset. Control is then transferred to IRAM after the kickstart loader is loaded. The kickstart loader then loads S1L from block 1 and on of NAND FLASH into IRAM. Once S1L is loaded, control is transferred to S1L.
View full article
The Future Designs LPC3250 based board ships with u-boot pre-installed. However, the kickstart loader and S1L can be installed on Future Designs LPC3250 boards. This will allow easier upgrade of the boot loader and the additional features and capabilities offered by S1L. Once installed, the kickstart loader resides in NAND block 0 and is loaded into IRAM with the LPC32x0 boot ROM on chip reset. Control is then transferred to IRAM after the kickstart loader is loaded. The kickstart loader then loads S1L from block 1 and on of NAND FLASH into IRAM. Once S1L is loaded, control is transferred to S1L. The kickstart loader concept and S1L are explained in more detail in the CDL boot loaderspage. S1L can be setup to load another application in IRAM or SDRAM. For Linux, u-boot can be setup to load and run in SDRAM at address 0x81fc0000. However, S1L isn't required and the kickstart loader can be built to load u-boot directly from NAND FLASH into SDRAM.
View full article
The Phytec LPC3250 based board ships with the kickstart loader and Stage 1 Loader pre-installed to execute from small block NAND FLASH. The kickstart loader resides in NAND block 0 and is loaded into IRAM with the LCP32x0 boot ROM on chip reset. Control is then transferred to IRAM after the kickstart loader is loaded. The kickstart loader then loads the Stage 1 Loader from block 1 and on of NAND FLASH into IRAM. Once S1L is loaded, control is transferred to S1L. The kickstart loader concept and S1L are explained in more detail in the Common Driver Library (CDL) boot loaders page. S1L initializes the board and SDRAM and then can be setup to load another application in IRAM or SDRAM. For Linux, u-boot can be setup to load and run in SDRAM at address 0x83fc0000. Because S1L and not the kickstart loader initializes SDRAM, u-boot must be loaded and started from S1L. However, S1L isn't required and the kickstart loader can be built to load u-boot directly from NAND FLASH into SDRAM. Note: The LPC32x0 attempts to boot from SPI FLASH first, NOR FLASH second, and NAND FLASH last. If a bootable image is located in SPI FLASH, the NOR FLASH and NAND FLASH boot methods will not work. Likewise, if an image is located in NOR FLASH, NAND FLASH boot will not work. If you want to boot from NAND FLASH, but have programmed an image into SPI or NOR FLASH, you will need to erase SPI or NOR FLASH first. Information about erasing these boot sources on the Phytec board can be found on the Erasing Phytec LPC3250 board FLASH page.   Restoring or updating the Phytec LPC3250 board's boot loaders If the kickstart loader or S1L is accidently erased in NAND FLASH, the board will fail to boot. The kickstart loader and S1L can be restored by following the procedure located on the Restoring or updating the Phytec LPC3250 board's boot loaders page.   Setting up to boot u-boot without S1L The Phytec LPC3250 board can be setup to boot u-boot from the kickstart loader without the use of S1L. This requires a special version of the kickstart loader that initializes SDRAM and loads u-boot from NAND FLASH directly into SDRAM. However, this version of the kickstart loader cannot reside in small block NAND FLASH due to boot image size limitations with small block NAND FLASH. It must boot from SPI FLASH or NOR FLASH. Information about configuring and setting up this capability can be found here on the [[Booting u-boot without S1L on the Booting u-boot without S1L on the Phytec LPC3250 board page. These configurations uses the SPI FLASH for boot with u-boot stored in NAND FLASH.   Booting from NOR FLASH u-boot can be setup to boot from NOR FLASH instead of NAND FLASH. For this setup, u-boot still loads and executes in SDRAM, but is stored and loaded from NOR FLASH instead of NAND FLASH. A small kickstart loader that initializes SDRAM executes from NOR FLASH on system reset and loads the u-boot image stored in NOR FLASH into SDRAM and then starts it. Information about configuring and setting up this capability can be found here on the Booting u-boot from NOR FLASH (without S1L) on the Phytec LPC3250 board page.
View full article
The LPC32x0 boots from SPI FLASH first, NOR FLASH second, and NAND FLASH last. The LPC32x0 will always attempt to boot from the first valid boot source based on a special boto pattern located at the start of the FLASH device. If you need to erase one of these FLASH boot sources, the procedure below can be used. Step 1: Download the pre-built boot software and restoration images for the Phytec LPC3250 board from the Resource page. Step 2: Extract the files on a Windows based PC Step 3: Connect a serial cable between the Phytec boards' lower serial connector and the PC 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 one of the eraser binary image files. To erase NOR FLASH, use the eraser_nor_rvw.bin file. For SPI FLASH, use the eraser_spi_rvw.bin file. For NAND FLASH, use the eraser_sb_nand_rvw.bin file. Verify that the Comport control selection matches the COM part on the PC that is connected to the Phytec board. The example below shows the configuration for erasing NOR FLASH. NOTE: The pre-built binaries may have slightly different names than those listed in step 5, 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 file names as necessary for you binaries you have.
View full article
CDL boot loader introduction The u-boot boot loader cannot be booted directly from the LPC32x0 boot ROM. Instead, a small loader program must be used to initialize the memory used by u-boot and then load it from it's non-volatile storage into memory before executing it. Because u-boot loads and executes from SDRAM, this initial loader must also initialize SDRAM. The CDL provides a reference boot loader called the kickstart loader that is meant to be the primary boot image loaded from the LPC3250 boot ROM. The kickstart loader can reside in NAND, NOR, or SPI FLASH and can be configured to load an image from any source into any address with any size. More information about the LPC32x0 boot process can be found on the LPC32x0 boot process page or in the LPC32x0 User's guide. The CDL has been ported to the Phytec, Embedded Artists, and Future Designs boards.   Kickstart loader and stage 1 definitions The terms kickstart loader and stage 1 application are used to describe the bootable images for the LPC32x0. A stage 1 application is the application we would ideally like to start when the LPC32x0 is reset or powered up. Stage 1 applications include programs such as u-boot, e-boot, or another full-featured application. Unfortunately, most stage 1 applications are too big to be directly booted by the LPC32x0 boot ROM. For systems where the stage 1 application can’t be directly booted, a smaller ‘kickstart’ boot loader is required to boot from the LPC32x0 boot ROM and then continue loading and start execution of the stage 1 application. For systems that boot from large block NAND FLASH or SPI FLASH, the maximum boot image size is 54K. If the application to be loaded exceeds this size or if the application needs to be loaded anywhere besides IRAM, the kickstart loader is required. The kickstart loader will in turn load the stage 1 application and transfer control to it after it has been loaded. If the application to be loaded is smaller than 54K and resides in IRAM, the stage 1 application can be directly loaded from the boot ROM instead of being routed through the kickstart loader. For systems that boot from small block NAND FLASH, the maximum boot image size is 15.5K. For systems that boot from NOR FLASH, no kickstart loader is needed (in most cases). The stage 1 application can be executed directly from NOR FLASH.   Kickstart loader The kickstart loader must be developed to be smaller than 54K (15.5K for systems that boot from small block NAND FLASH). This loader can include startup code that sets up the board’s initial GPIO states and muxes, setup the initial clocking, setup a basic MMU table if needed, setup all the memory interface, and then load an image and transfer control to that image. For small block NAND systems with the 15.5K boot image limit, this can be tough to manage. Tradeoffs may need to be made on what functions can be handled by the kickstart loader. Enabling all the functions may make a kickstart image that exceeds 15.5K. The image size would have to be reduced in this case by removing features from the kickstart loader and moving them to the stage 1 application. If your stage 1 application needs to execute in SDRAM, but the kickstart is too large with all the SDRAM init code, then code needs to be rearranged or aggressively optimized to meet the boot image size limitation.   Kickstart loader bootup procedure The following sequence shows how the LPC32x0 handles kickstart load and transfer from the boot ROM using NAND or SPI FLASH. LPC32x0 processor is reset LPC32x0 boot ROM interrogates boot devices For SPI FLASH, the image loaded at SPI FLASH offset 8 is loaded into IRAM at address 0x0 For NAND FLASH, the image loaded in page 1 of block 0 or 1 is loaded into IRAM at address 0x0 After the image is loaded, the boot ROM transfers control to the image’s startup code loaded at address 0x0   Stage 1 applications Stage 1 applications are applications that meet one of the following criteria: Loads and executes directly from the UART into IRAM Loads and executes from the kickstart loader in IRAM or SDRAM Loads and executes in place from NOR FLASH For Linux, u-boot can be considered a stage 1 application. For the Phytec and Embedded Artists boards, the kickstart loader loads S1L as the stage 1 application. S1L initializes the board functions such as clocking and SDRAM and then loads and starts u-boot. Optionally, the kickstart loader can use u-boot as the stage 1 application bypassing S1L. Stage 1 Loader The Stage 1 Loader (S1L) is an optional stage 1 application that provides debug, monitor, and boot support for an NXP micro controller. It can be used as the initial boot image the micro controller executes and then configured to load another image automatically. S1L is included free as part of the LPC32x0 CDL and is pre-installed on the Embedded Artist and Phytec LPC3250 based development boards. It can also be installed on Future Design LPC3250 based boards.The main features of the stage 1 loader are shown below: Register and memory change and dump Poke, peek, dump, fill Image load via a serial port , SDMMC card, or FLASH Supports raw binary and S-record files Images can be executed after loading Images can be saved in NAND FLASH NAND FLASH support Erase of NAND blocks Direct read and write of FLASH blocks and pages Bad block management MMU functions Data and instruction cache control Virtual address translation enable/disable Virtual address remapping Page table dump System support functions Baud rate control, clock control, system information Automatic load and run support Automatic load and execution of images from NAND FLASH, SDMMC, or via the terminal Testing functions SDRAM memory tests, bandwidth tests SDRAM calibration and configuration data   Other features of the CDL This CDL provides a generic set of drivers which highlight how specific peripherals and functions work. The CDL also provides Board Support Packages (BSP) for development boards based on the LPC32x0 microcontrollers. The BSPs provide reference code for system startup including boot loaders, system clock setup, SDRAM setup, and MMU/cache setup.The CDL provides the following features: Various drivers and header files for the LPC32x0 microcontroller Common software and definitions for LPC32x0 microcontrollers Support for Keil uVision4, ARM Realview 3.1, and GNU CodeSourcery tool chains BSPs for Embedded Artists, Phytec, and Future Designs LPC3250 based development boards A reference BSP for the NXP LPC32x0 based validation and reference platform A generic BSP that contains universal startup code for easy porting to a new LPC32x0 based platform Free for use with NXP LPC32x0 microcontrollers The Phytec, Embedded Artists, and Future Designs LPC3250 BSPs provide the following features: Startup code and board initialization code based on the board’s possible boot modes and devices Software to re-burn the boot loaders into NAND, SPI, or NOR FLASH Updated versions of the kickstart loader and S1L applications Tool-less software deployment options when used with the Stage 1 Loader or the Serial Loader Various peripheral examples that can downloaded and executed via S1L or a debugger Quickstart instructions The NXP LPC32x0 validation and reference platform is not commercially available, although the code included in the BSP is provided as part of the CDL. A generic LPC32x0 BSP is also provided as part of this CDL. This generic BSP provides the following features: Configurable startup code and board initialization code Standard and mobile single and double data rate SDRAM reference code based on the JEDEC SDRAM initialization sequence Reference drivers for small and large block NAND FLASH using the MLC and SLC controllers SPI FLASH and NOR FLASH reference drivers Burner software for burning and updating images in NAND, SPI, or NOR FLASH Various kickstart loader and S1L examples for multiple deployment methods Ideal for new board bringup (support for IRAM only boot via the Serial loader tool) Documentation that explains the reasoning and structure of the software
View full article
Attached is another simple SWIM demo that setups a 240x320 window and draws an animated diamond in the window as fast as possible. Although the code is meant to be used with the LPC32x0 CDL, it can be easily ported to other devices. The code for setting up the window and doing the animations is below: /* Create a SWIM window */ swim_window_open(&win1, LCD_DISPLAY.pixels_per_line,     LCD_DISPLAY.lines_per_panel, fblog1, 0, 0,     (LCD_DISPLAY.pixels_per_line - 1),     (LCD_DISPLAY.lines_per_panel - 1), 3, WHITE, BLACK, MAGENTA);     xf = 20;     yf = 30;     xinc = 1;     yinc = 1;     clr = RED | GREEN;     /* Draw as fast as possible, no throttling */     while (1)     {        swim_set_fill_color(&win1, clr);        swim_put_diamond(&win1, LCD_DISPLAY.pixels_per_line / 2,        LCD_DISPLAY.lines_per_panel / 2, xf, yf);        lcd_ioctl(lcddev, LCD_SET_UP_FB, PHY_LCD_FRAME_BUF1);        xf += xinc;        if ((xf < 10) || (xf > 150))            xinc = -xinc;        yf += yinc;        if ((yf < 10) || (yf > 230))            yinc = -yinc;        clr++;        if (clr > 0xFFFF)            clr = RED | GREEN;     } The file also includes a pre-built image of the program for use with the Phytec LPC3250 board using S1L. To use the image, just boot the board to the S1L prompt, type "load term srec', send the SREC file to the board via the serial port (no transfer protocol), and then type 'exec' to start it.
View full article
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>
View full article
Even when new, NAND devices may have bad blocks. A bad block may be a block that has a bit failure or cannot erase properly. Vendors typically provide a pre-built map of known existing bad blocks for each part. The factory bad blocks are marked with by a non-0xFF value in the factory bad block marker offset on the first page of each block. For small page devices, this factory offset is usually bytes 516 and 517 in a page. For large page devices, this factory offset is usually 2048. You can get a list of bad blocks by scanning the first page in each block on a NAND device and checking if the value in the factory bad block marker offset in the data is a non-0xFF value. The SLC NAND controller and all NXP developed software for the SLC NAND controller (Linux, WinCE, or standalone) uses the same locations as the factory markers for bad block marking and detection. Because of this, no special processing or relocation of the bad blocks is needed for a NAND device. The MLC NAND controller can only read and write data with ECC in 528 byte chunks. Because of this, the data and ECC values are interleaved in the NAND page. The factory bad block markers with this scheme cannot be used. If the MLC NAND controller must be used for anything besides chip boot, the factory bad block markers need to be recorded and moved prior to writing data to the device. In the case of block 0, which is use for NAND boot on the LPC32x0 using the MLC controller, no bad block detection or marking is used in any NXP software. This is because NAND device manufacturers typically guarantee the data reliability of block 0 for a limited number (ie, 1000) of write cycles.
View full article
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.
View full article
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
View full article
The NXP motor control library (nxpMClib) supports various types of motor control for the Cortex-M family. Built on CMSIS2.0 math and DSPLIB. Supported by motor control GUI with selection for each supported type. Includes real time data view comm library. Currently available examples: lpc18xx/43xx FOC dual shunt Watch this Video of the FOC implementation: Video Field Oriented Control on the NXP LPC1800 Microcontroller Library layers The motor control library is separated in four layers. The bottom layer contains the peripheral drivers. On top of the driver layer is a generic collection of control algorithms to drive the peripherals. On top of that resides the layer that defines the motor control type and contains the state machines to drive the specific type. Finally there is the application layer that determines the interfaces to the library and initializes the application specific motor control type, peripheral setup and interconnection. Download Get the latest software package including the library, example code, the tool installer and documentation attached.
View full article
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."
View full article
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.
View full article
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)
View full article
The LPC LWIP port uses zero-copy buffers. Zero-copy buffers can improve system performance over copied buffers when transferring large amounts of ethernet data. Zero-copy buffers also use less memory for data storage, as bounce buffers are not needed between the LWIP pbufs and the ethernet DMA buffers. This section gives a brief overview of how buffers are managed in the driver and the LWIP applications. Zero-copy RX buffers For zero-copy buffers, the initial pbufs needed to receive packets are pre-allocated and assigned to the ethernet controller at the maximum expected packet size. It should be noted that the payload for the packet in a pbuf must always be non-chained (contiguous) for receive. The driver will allocate packets with maximum packet size without any chaining. When a packet is received, the hardware places the received data directly into the pbuf's data (payload) area. The pbuf is then passed to the network layer without an extra copy where it is used by the application or LWIP and then de-allocated once it finishes with the packet. Once the pbuf leaves the driver's functions, it no longer tracks it or it's buffer, but the original descriptor that was associated with the pbuf is now available for a new pbuf. The driver will attetmpt to allocate and requeue a new pbuf for the descriptor before returning the received packet. If memory is not available for the new pbuf, the descriptor remains free and an attenpt will be made to allocate a new pbuf on the next received packet. (Calling lpc_rx_queue() anytime will also attempt to reload any idle RX descriptors). Note: For the LPC17xx, the descriptors and buffers must be located only in peripheral RAM or external memory. For the LPC18xx/43xx, descriptors and buffers can be located anywhere. Zero-copy TX buffers For zero-copy buffers, the initial pbuf's payload addresses are used directly with the EMAC TX descriptors. The driver will chain buffers in the descriptor if needed (if a chained pbuf is used) and keep a reference of the pbufs that are used for the transfer. The buffers/pbufs must remain in memory until the EMAC has transferred the data related to the pbuf(s). Once the EMAC transfers the buffers, the pbuf(s) will be de-allocated by the driver. Note: For the LPC17xx, the descriptors and buffers must be located only in peripheral RAM or external memory. For the LPC18xx/43xx, descriptors and buffers can be located anywhere. Zero-copy TX buffers and bounce buffers In some cases, buffers may be passed to the driver that are located in FLASH memory, IRAM, or slow memory. The EMAC driver and peripheral can't send this data directly via DMA (due to architecture or speed restrictions), so the data needs to be relocated to an area of memory that it can be sent from. If the driver detects that a buffer address used for a zero-copy transfer is not usable by the EMAC, it will copy the buffer to a temporary bounce buffer and send it from that buffer instead. This occurs automatically inside the driver if the bounce buffer support is enabled. If the bounce buffer support is not enabled and a non-usable buffer is detected, the driver will raise an exception. For the LPC17xx, this support is enabled by setting LPC_TX_PBUF_BOUNCE_EN to 1. For the LCP18xx/43xx, this support is enabled by setting LPC_CHECK_SLOWMEM to 1. If LPC_CHECK_SLOWMEM is set to 1, the memory ranges for the check must be setup with the LPC_SLOWMEM_ARRAY define.
View full article