LPCware Archive Content

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

LPCware Archive Content

Discussions

Sort by:
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
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
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
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 This page gives more detailed information on how to use the IOH libraries in custom projects when using the Keil MDK IDE. For more general information regarding using IOH libraries in custom project or for detailed instructions for LPCXpresso and IAR EWARM, visit IOH: Getting started with IOH in custom projects. Ready-to-use examples can be found at the main I/O Handler page. Note: This guide assumes the IOH I2S library is to be added to a project, hence the 'I2S' references. For other IOH libraries, 'I2S' should be replaced with the library name. 1. Add the IOH library (ioh_*_keil.lib) to the project The first step is to configure the Keil project to link against the IOH library. This can be done by simply adding the .lib file to the project. 2. Add the path where the library's header file resides to the project’s include path The next step is to add the file location of the library's header file to the include path of the project. Open the project options and browse to the tab 'C/C++'. Add the location of the header file to the 'Include Paths'. 3. #include the IOH header file in the source code of the application The IOH header file must be included in the source code of the project (e.g. main.c) by using the following preprocessor directive: #include "IOH_I2S.h" 4. Configure the linker to place the IOH related sections in the IOH SRAM All IOH parts have an SRAM region reserved for I/O Handler. When starting IOH, usually by calling the library's init() function, I/O Handler expects this memory region to be loaded with the IOH data provided by the IOH library. This means this data must be stored in Flash and copied to the IOH SRAM upon startup. A convenient way to do this, is by using scatter loading. With scatter loading, the linker and c-library are instructed to program certain data sections (IOH data) into Flash, and copy it to the specifed region (IOH SRAM) upon start up. This requires a linker script. The linker script can be added to the keil project by opening the projects options and browsing to the 'Linker' tab. First uncheck the 'Use memory Layout from Target Dialog' checkbox, then add the file location to the 'Scatter file' box. Following is the linker script used for the LPC11U37H, placing the IOH sections in the SRAM1 region (IOH SRAM): LR_IROM1 0x00000000 0x00020000  {    ; load region size_region   ER_IROM1 0x00000000 0x00020000  {  ; load address = execution address    *.o (RESET, +First)    *(InRoot$$Sections)    .ANY (+RO)       }   RW_IRAM1 0x10000000 0x00002000  {  ; RW data    .ANY (+RW +ZI)   }   RW_IRAM2 0x20004000 0x00000800  {  ; RW data    .ANY (+RW +ZI)   }   RW_IRAM3 0x20000000 0x00000800  {  ; RW data    .ANY(.ioh_text)    .ANY(.ioh_constdata)    .ANY(.ioh_bss)    .ANY(.ioh_data)   } } 5. Enable the IOH SRAM (SRAM1) before C-library initialization The copying of data from the 'load region' to the 'execution region' when using scatter loading (explained above) is executed by the c-library just before main() gets called. It's important that both regions are enabled when the copying is initiated. After power-on, the IOH SRAM on the LPC11E/U37H is disabled (clock disabled in the SYSAHBCLKCTRL register), so it must be enabled before the scatter loading is initiated. The right place (assuming the CMSIS standard is followed) to enable the IOH SRAM, is in the SystemInit function. SystemInit() is called just before the C-enviroment is initialized as can been seen from the following snippet from the LPC11xx Keil startup file: Reset_Handler   PROC EXPORT  Reset_Handler             [WEAK] IMPORT  SystemInit IMPORT  __main LDR     R0, =SystemInit BLX     R0 LDR     R0, =__main BX      R0 ENDP Therefore the SystemInit() function should contain the code for enabling the IOH SRAM block, e.g. by adding the following line to the SystemInit() function (assuming the LPC11E/U37H): LPC_SYSCON->SYSAHBCLKCTRL |= (1<<26); 6. Interact with IOH via the library's API The final step is to interact from the application with IOH. This can be done through the library's API. Each library comes with an application note explaining how to use the library and what data structures and functions are available, and with one or more application examples showing how to use the library. This application note and application example provide an easy way to get started. They can be downloaded from the main I/O Handler page.
View full article
Introduction The LPC4088 based Closed Loop Payment demo shows how a basic closed loop payment system can be created using NXP’s ARM Cortex-M4 based LPC4088.  The leading industry-standard MIFARE contactless and dual interface smart card is used for payment and is fully compliant with ISO 14443A. A 7” 800x480 color touch-screen LCD functions as a graphical user interface (GUI). Using this graphical interface, the card can be queried, items to buy can be selected, and finally the user can proceed to checkout.  The GUI is build using emWin. NXP's CLRC663, a contacless reader IC, is used to interface with the MIFARE card. This demo also features the usage of the SPIFI peripheral. A 32Mbit QSPI FLASH chip is used for storing images used by the demo. Demo Video Links NXP Secure Transaction Website on EETimes LPCWare emWin project page NXP ARM Cortex-M4 Product Page NXP CLEV663B demoboard (Blueboard) Getting started with the RC663 Blueboard Embedded Artists LPC1788 Evaluation Board (LPC4088 OEM module required for this demo) Embedded Artists LPC4088 Developers Kit (Baseboard + LPC4088 OEM module) Embedded Artists 7" 800x480 color LCD Software Encryption Solutions
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
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
If you already have S1L on your FDI board, you can update to a previous or later version of S1L with the following procedure. This procedure should not be used to update the kickstart loader in block 0. Step 1: Boot the system to the S1L prompt. Have your updated version of S1L ready. Step 2: At the S1L prompt, type 'load term raw 0x90000000' to start the binary receive in S1L of the new image. On your terminal program, send the S1L file (ie, s1l_from_kick_gnu.bin) to the board as a binary file. Step 3: Once transfer completes, send a break to the board to return to the prompt. In TeraTerm, a break can be sent from the Control menu or by pressing ALT-B. Step 4: Erase the blocks in FLASH used for S1L storage. These are blocks 1 to 24. Be very careful not to erase block 0, which is used for the klickstart loader. The 'erase 1 24' command can be used to erase the blocks. Step 5: Write the loaded S1L image into the S1L area starting at block 1. The S1L image is usually between 56K and 80K, so it will easily fit in 1 block. The command 'write 0x90000000 64 64' will perform this operation. The write command take sectors (not blocks) - sector 64 is where block 1 starts. Step 6: Reset the board to verify the S1L image has been updated. The entire sequence is shown below. You can see a different version of S1L is running by examining the build date of S1L when it boots. FDI3250 Kickstart v1.00 NAND Flash Initialized Running Stage 1 Loader ... Future Designs, Inc. DK-xTS-LPC3250 Board Build date: Sep 10 2010 10:12:22 Autoboot in progress, press any key to stop linux>load term raw 0x90000000 Starting terminal download, send break to stop File loaded successfully linux>erase 1 24 Operation will overwrite bootloader - ok?(y/n): Starting block erase linux>write 0x90000000 64 64 linux>FDI3250 Kickstart v1.00 NAND Flash Initialized Running Stage 1 Loader ... Using default system configuration Future Designs, Inc. DK-xTS-LPC3250 Board Build date: Sep 13 2010 11:20:12 FDI3250
View full article
Description This example implements a HID class device with mouse report descriptors. Key character reports are sent to the host by the device when buttons are pressed or the joystick is moved on the development board. 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_KeyboardDevice Configure MCU   right click on the Example_KeyboardDevice 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_Device LPC18xx LPC1850 LPC4330  / Xplorer LPC4330_Xplorer LPC18xx LPC18xx_Device LPC18xx LPC4330 LPC4350  / Element14 LPC1435_ELEMENT14 LPC18xx LPC18xx_Device LPC18xx LPC4350 LPC11U14 / LPCXpresso LPC11Uxx_LPCXpressoRevB LPC11Uxx LPC11Uxx_Device LPC11Uxx LPC11U14 LPC11U14 / MCB1000 LPC11u14_MCB1000 LPC11Uxx LPC11Uxx_Device LPC11Uxx LPC11U14 LPC1768  / MCB1700 LPC1768_MCB1700 LPC17xx LPC17xx_Device LPC17xx LPC1768 LPC1768  / LPCXpresso LPC17xx_LPCXpressoRevB LPC17xx LPC17xx_Device 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_Device, and Example_KeyboardDevice BSP CDL nxpUSBlib_Device Example_KeyboardDevice LPC1850  / Hitex HITEX1800 LPC18xx LPC18xx_Device HITEX1800 LPC1768  / MCB1700 MCB1700 LPC17xx LPC17xx_Device MCB1700 LPC11U14 / MCB1000 MCB1000 LPC11Uxx LPC11Uxx_Device MCB1000   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 the type-B end of a USB cable to the receptacle marked X2. Plug the type-A end of this cable into a PC LPC18xx_HITEX (LPC1850 Hitex Evaluation Board)  newer A4 design schematic ./BSP/schematics/HITEX_Final_LPC1850EVA-A3.pdf   LPC4330_Xplorer (NGX Xplorer Evaluation Board with LPC4330) Connect the JTAG to the 10 pin receptacle marked J2 Connect the micro-b end of a USB cable to the receptacle marked USB0. Plug the type-A end of this cable into a PC   LPC1435_ELEMENT14 (Element 14 gaming board with LPC4350) Connect the JTAG to the 10 pin receptacle marked J6 Connect one end of a type-A to type-A USB cable to the receptacle marked USB0. Plug the other end of this cable into a PC   LPC11u14_MCB1000 (Keil MCB1000 development board) schematic: ./BSP/schematics/mcb1000-schematics.pdf   Jumpers:   J4 = 2-3      (UCON - PIO0_6 pulls D+ high)   J2 = 1-2          (VDD  - core power)   J5 not installed  (ISP  - ISP via COMM)   J6 not installed  (RST  - ISP via COMM) Connect the JTAG debugger to the 10 pin Cortex Debug connector labeled J3 Connect the type-B end of a USB cable to the type-B recepticle and the type-A end of the cable to the USB receptacle on a PC Once the USB cable is connected to the board the following LEDs should be illuminated:     Power     All 8 LEDs in PIO2   LPC1768_MCB1700 (Keil MCB1700 development board) schematic: ./BSP/schematics/mcb1700-schematics.pdf   Jumpers:   E/U    = 1-2  (Ethernet/USB)   UMODE  = 1-2  (USB Device Mode)   D-     = Device   D+     = Device   VBUS   = 1-2   VDDIO  = 1-2   VDDREG = 1-2   Connect the JTAG debugger to the 20 pin JTAG or 10 pin Cortex Debug connector. Connect the type-B end of a USB cable to the type-B recepticle labeled 'Device' and the type-A end of the cable to the USB receptacle on a PC. Once the USB cable is connected to the board the following LEDs should be illuminated:     Power     100MHz     USC (LED indicates a USB soft connect from P2.9)    LPC11Uxx_LPCXpressoRevB (LPCXpresso LPC11Uxx on the LPCXpresso Rev B base board) schematic: ./BSP/schematics/lpcxpresso.lpc11u14.schematic.pdf   Running this example on the LPCXpresso LPC11U14 can be done one of two ways:   1. LPCXpresso LPC11U14 stand-alone       Connect the type-B end of a USB cable to the mini receptacle on the LPCXpresso board labeled J8 and the type-A end to the USB receptacle on a PC   2. LPCXpresso LPC11U14 plugged into the LPCXpresso base board Rev B       Plug the LPCXpresso LPC11U14 board into the connector labeled J4 on a LPCXpresso base board Rev B       Configure the base board according to the user's guide from Embedded Artists       Connect the mini type-B end of a USB cable to the receptacle on the base board labeled X1 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)         For both configurations the JTAG debugger is connected to the mini USB receptacle labeled J3 on the LPCXpresso LPC11U14 board   LPC17xx_LPCXpressoRevB (LPCXpresso LPC17xx on the LPCXpresso Rev B base board) schematic: ./BSP/schematics/LPCXpressoLPC1769revB.pdf   Running this example on the LPCXpresso LPC1769 can be done one of two ways:   1. LPCXpresso LPC1769 stand-alone. Solder a type-B USB receptacle onto the board and wire it up. See included schematics for details. Connect the type-B end of a USB cable to the receptacle on the LPCXpresso board and the type-A end to the USB receptacle on a PC   2. LPCXpresso LPC1769 plugged into the LPCXpresso base board Rev B. Plug the LPCXpresso LPC1769 board into the connector labeled J4 on a LPCXpresso base board Rev B. Configure the base board according to the users guide from Embedded Artists. Connect the mini type-B end of a USB cable to the receptacle on the base board labeled X1 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)         For both configurations the JTAG debugger is connected to the mini USB receptacle labeled J3 on the LPCXpresso LPC1769 board.   PC configuration Use a PC running Windows XP, Vista or 7 Connect the type-A end of the USB cable that is connected to the board into one of the USB receptacles on the PC Build and debug the example LPCXpresso IDE In the project explorer window of the IDE right click on the Example_KeyboardDevice 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 run and the board is connected to a PC with a USB cable it will enumerate on the PC as a HID Keyboard device. You should see the device appear in the "Device Manager" under "Keyboards". If you right click on HID Keyboard Device->Properties a window will appear called "HID Keyboard Device Properties". If you select the "Details" tab you will see a "Properties" drop down, click on it and select "Hardware Ids". You should see the below entries for Vendor Id and Product Id.   HID\VID_1FC9&PID_2042&REV_0001 HID\VID_1FC9&PID_2042   This information should match the data in the "Device Descriptor Structure" in the "Descriptors.c" file in the Example_KeyboardDevice project directory.   To demostrate the keyboard open an editing application such as Notepad or MS Word. Moving the joystick (SW2) on the Xpresso base board will output characters onto the editing application.
View full article
Description This example implements an audio interface class host mode device that enumerates an audio interface class device (USB speakers) and sends samples to the device. The samples are created by a simple square wave generator in a timer ISR and shipped out the streaming isochronous output pipe when a button is pressed on the board. Getting started This example can be built and debugged using two compiler tool chains. Visit http://www.lpcware.com/content/project/nxpusblib/build-it to learn how to setup and configure these tool chains to build 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_AudioOutputHost Configure MCU   right click on the Example_AudioOutputHost 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_AudioOutputHost MCU LPC1850  / Hitex LPC18xx_HITEX LPC18xx LPC18xx_Host LPC18xx LPC1850 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_Device, and Example_AudioOutputHost BSP CDL nxpUSBlib_Host Example_AudioOutputHost LPC1850  / Hitex HITEX1800 LPC18xx LPC18xx_Host HITEX1800 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 Plug USB speakers 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 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_AudioOutputHost 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: Audio Output Host Demo running. When the USB speakers are plugged in the terminal window will display: Audio Device Enumerated. When the button is pressed on the board the USB speakers will produce a loud tone. When the button is not pressed the USB speakers will be silent. When the USB speakers are unplugged the terminal window will display: Device Unattached.
View full article
These instructions explain how to use the CodeSourcery GNU tools to build a LWIP project and variant. GNU builds are based on the free CodeSourcery Codebench Lite version. Download the CodeSourcery Lite GNU tools Prior to building the code, you'll need to CodeSourcery GNU tools. These can be download from Mentor Graphics. There are multiple versions of the tools that can be download. Make sure you download the EABI version of the tools with CodeBench. These will be identified similar to "Sourcery CodeBench Lite 2011.09-69 for ARM EABI". The IA32 Windows Installer version was used to generate the projects included in the LWIP packages. After the tools are downloaded, install the tools onto your build machine. Build system and source code modifications Before you can build the projects, a few manual modifications of the source code and a few make related files are needed. lpc177x_8x_emac.c Locate the lpc177x_8x_emac.c and open it for editing. Wrap "#if 0/#endif" clauses around the ENET_IRQHandler function. This will prevent build problems when using the interrupt handler of the same name as part of the LWIP driver. makeconfig Locate the makeconfig file in the makesection folder.If needed, change the path and version number to what's been installed for your host machine. #GNU_INSTALL_ROOT    =C:/Program Files (x86)/CodeSourcery/Sourcery G++ Lite GNU_INSTALL_ROOT    =C:/Program Files (x86)/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI GNU_VERSION               =4.3.3 make.LPC177x_8x.gnu Locate the make.LPC177x_8x.gnu file in the makesection/LPC177x_8x folder. Make changes as needed to this file for your build. For example, only the changes below were needed. OPTIM            = s CC                 = $(GNUTOOLS)/arm-none-eabi-gcc #CC               = $(GNUTOOLS)/arm-none-eabi-gcc-$(GNU_VERSION) Build procedure Add make tools to system environment path Once the changes have been made, open up a CMD (cmd.exe) shell for your Windows host machine. In the shell, switch to the directory with the example project (ie, ea1788_tcpecho_sa) and then into the gnu subfolder in that project. Run theaddtoolpath.bat script to add the tools path to your shell's environment. C:\dev\git\lwip_work\updated\lpc177x_8x\lwip_lpc\nxpcommon\examples\ea1788\ea1788_tcpecho_sa\gnu>set PATH=..\..\..\..\..\..\makesection\tools;..\..\..\..\..\..\makesection\tools;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\TortoiseSVN\bin;C:\Program Files\TortoiseGit\bin;C:\Keil421\ARM\BIN40;C:\Program Files (x86)\doxygen\bin;C:\Program Files (x86)\Enterprise Vault\EVClient\;C:\Program Files (x86)\CodeSourcery\Sourcery_CodeBench_Lite_for_ARM_EABI\bin;C:\Program Files (x86)\CodeSourcery\Sourcery G++ Lite\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\TortoiseSVN\bin;C:\Program Files\TortoiseGit\bin;C:\Keil421\ARM\BIN40 C:\dev\git\lwip_work\updated\lpc177x_8x\lwip_lpc\nxpcommon\examples\ea1788\ea1788_tcpecho_sa\gnu> Make the image Then type make to build the project. If your project builds without errors, you should get a hex file that can be programmed into the board usng the Flash Magic tool. port/sdram_k4s561632j.o C:/dev/git/lwip_work/u2/lpc177x_8x/lwip_lpc/nxpcommon/examples/ea1788_tcpecho_sa/gnu/../../../../../BoardSupport/sdram_mt48lc8m32lfb5.o C:/dev/git/lwip_work/u2/lpc177x_8x/lwip_lpc/nxpcommon/examples/ea1788_tcpecho_sa/gnu/../../../../../BoardSupport/sensor_smb380.o C:/dev/git/lwip_work/u2/lpc177x_8x/lwip_lpc/nxpcommon/examples/ea1788_tcpecho_sa/gnu/../../../../../BoardSupport/transceiver_sn74lvc16245.o C:/dev/git/lwip_work/u2/lpc177x_8x/lwip_lpc/nxpcommon/examples/ea1788_tcpecho_sa/gnu/../../../../../BoardSupport/uda1380.o   lpc_emac.o lpc_emac_zcbuffs.o lpc_phy.o lpc_debug.o sys_arch.o Serial.o lpc177x_8x_systick_arch.o retarget.o ea1788_board.o tcpecho_sa_app.o def.o dhcp.o dns.o init.o mem.o memp.o netif.o pbuf.o raw.o stats.o sys.o tcp.o tcp_in.o tcp_out.o timers.o udp.o autoip.o icmp.o igmp.o inet.o inet_chksum.o ip.o ip_addr.o ip_frag.o etharp.o echo.o  -static -mcpu=cortex-m3 -mthumb -mthumb-interwork -Wl,--start-group  -L'C:/Program Files (x86)/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/lib/gcc/arm-none-eabi/4.3.3/thumb2' -L'C:/Program Files (x86)/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/arm-none-eabi/lib/thumb2' -lc -lg -lstdc++ -lsupc++  -lgcc -lm  -Wl,--end-group   -Xlinker -Map -Xlinker \ea1788_tcpecho_sa.map -Xlinker -T   linker/ldscript_dram_zc_gnu.ld -o ea1788_tcpecho_sa.elf 'C:/Program Files (x86)/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin'/arm-none-eabi-objcopy -O ihex  ea1788_tcpecho_sa.elf ea1788_tcpecho_sa.hex 'C:/Program Files (x86)/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin'/arm-none-eabi-objcopy -O srec  ea1788_tcpecho_sa.elf ea1788_tcpecho_sa.srec C:/dev/git/lwip_work/u2/lpc177x_8x/lwip_lpc/nxpcommon/examples/ea1788_tcpecho_sa/gnu/../../../../../makesection/tools/mkdir -p GCC\Flash C:/dev/git/lwip_work/u2/lpc177x_8x/lwip_lpc/nxpcommon/examples/ea1788_tcpecho_sa/gnu/../../../../../makesection/tools/mv -f ea1788_tcpecho_sa.map GCC\Flash\ea1788_tcpecho_sa.map C:/dev/git/lwip_work/u2/lpc177x_8x/lwip_lpc/nxpcommon/examples/ea1788_tcpecho_sa/gnu/../../../../../makesection/tools/mv -f ea1788_tcpecho_sa.elf GCC\Flash\ea1788_tcpecho_sa.elf C:/dev/git/lwip_work/u2/lpc177x_8x/lwip_lpc/nxpcommon/examples/ea1788_tcpecho_sa/gnu/../../../../../makesection/tools/mv -f ea1788_tcpecho_sa.hex GCC\Flash\ea1788_tcpecho_sa.hex C:/dev/git/lwip_work/u2/lpc177x_8x/lwip_lpc/nxpcommon/examples/ea1788_tcpecho_sa/gnu/../../../../../makesection/tools/mv -f ea1788_tcpecho_sa.srec GCC\Flash\ea1788_tcpecho_sa.srec 'C:/Program Files (x86)/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin'/arm-none-eabi-size GCC\Flash\ea1788_tcpecho_sa.elf    text    data     bss     dec     hex filename   70376     216 4611064 4681656  476fb8 GCC\Flash\ea1788_tcpecho_sa.elf Once the image has been built, you can use Flash Magic to program the image into internal FLASH using the generated HEX file.
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
If you accidentally erase the kick start or S1L boot loaders on the Phytec 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 Phytec board. The original versions of the boot loaders can also be downloaded from Phytec's website. 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 serial port to perform the update procedure. Restoring the kick start loader and S1L is a 2-step process. The kick start loader is restored first and then S1L 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 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 the burner_kickstart_nand_small_block_rvw.bin file. Setup the 'Secondary Executable (SDRAM)' file in the Serial loader to the kickstart_nand_small_block_rvw.bin file. Verify that the Comport control selection matches the COM part on the PC that is connected to the Phytec 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_small_block_rvw.bin file. Setup the 'Secondary Executable (SDRAM)' file in the Serial loader to the s1l_from_kick_full_rvw.bin file. Verify that the Comport control selection matches the COM part on the PC that is connected to the Phytec board.   Step 8: Press the 'Load bin's / Start primary' button on the Serial loader and reset the board. The burner image and the S1L image should transfer to the board and S1L 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 S1L should start.   5 Phytec 3250 Board Build date: May 21 2010 12:43:21 PHY3250>
View full article
Description This example implements an audio interface class device mode device that enumerates as audio device (USB speakers) and sends the samples sent to it from the host to the audio circuitry on the board.   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. NOTE: read the Design notes section below if you are running this example on a part that supports high speed controllers.   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_AudioOutputDevice   Configure MCU   right click on the Example_AudioOutputDevice 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_AudioOutputDevice MCU LPC1850  / Hitex LPC18xx_HITEX LPC18xx LPC18xx_Device LPC18xx LPC1850 LPC4330  / Xplorer LPC4330_Xplorer LPC18xx LPC18xx_Device LPC18xx LPC4330 LPC4350  / Element14 LPC1435_ELEMENT14 LPC18xx LPC18xx_Device LPC18xx LPC4350 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_Device, and Example_AudioOutputDevice BSP CDL nxpUSBlib_Device Example_AudioOutputDevice LPC1850  / Hitex HITEX1800 LPC18xx LPC18xx_Device HITEX1800   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 the type-B end of a USB cable to the receptacle marked X2. Plug the type-A end of this cable into a PC Connect the mini-phono plug on a pair of headphones to the receptacle marked HP   LPC18xx_HITEX (LPC1850 Hitex Evaluation Board)  newer A4 design schematic ./BSP/schematics/HITEX_Final_LPC1850EVA-A3.pdf LPC4330_Xplorer (NGX Xplorer Evaluation Board with LPC4330) Connect the JTAG to the 10 pin receptacle marked J2 Connect the micro-b end of a USB cable to the receptacle marked USB0. Plug the type-A end of this cable into a PC Connect the mini-phono plug on a pair of headphones to the receptacle marked J5 LPC1435_ELEMENT14 (Element 14 gaming board with LPC4350) Connect the JTAG to the 10 pin receptacle marked J6 Connect one end of a type-A to type-A USB cable to the receptacle marked USB0. Plug the other end of this cable into a PC Connect the mini-phono plug on a pair of headphones to the receptacle marked J1 PC configuration Use a PC running Windows XP, Vista or 7 Connect the type-A end of the USB cable that is connected to the board into one of the USB receptacles on the PC Build and debug the example LPCXpresso IDE In the project explorer window of the IDE right click on the Example_AudioOutputDevice 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 On the PC select Control Panel->Hardware and Sound->Sound When the example is first run a new entry in the Sound dialog box will appear titled Speakers and have a description that reads "4-nxpUSBlib Audio Out Demo". Below this description should be the word Ready.   To test the audio output click on this entry in the Sound dialog box. Then click on the Configure button to bring up the Speaker Setup dialog box. In this box press the Test button. Sound should be played through the left side of your headphones first, then the right side. Design notes This example is designed to run only at full speed. The nxpUSBlib runs the USB controllers on the LPC18xx and LPC43xx parts at high speed by default. This default must be changed to run this example properly on these parts. To do this, change the value of the definition USB_FORCED_FULLSPEED in the file libraries/nxpusblib/nxpUSBlibConfig.h to 1
View full article
NicheLite for LPC by InterNiche is a variant of its NicheLite™ product, a full-featured TCP/IP stack optimized for embedded systems, requiring as little as 12 KB of code. An RFC compliant implementation of the TCP/IP protocol suite, NicheLite for LPC includes ANSI C sources for a comprehensive subset of the TCP/IP family of protocols, a "Mini" Sockets API, and a highly effective system optimization and tuning tool. NicheLite for LPC's IP layer can support one hardware interface and is fully instrumented for MIB-II access by SNMP agents. MIB-II tables include: Interfaces, IP, ICMP, TCP and UDP information. Packet data, including headers, are in contiguous buffers to simplify memory management and avoid data copies. Macros to protect critical sections of code are used sparingly to improve throughput and reduce memory requirements. The tunable parameters such as MSS (Maximum Segment Size) and the TCP window size can be left to the runtime logic or may be customized for your application. NicheLite for LPC supports the following protocols: Address Resolution Protocol (ARP) Internet Protocol (IP) Internet Control Message Protocol (ICMP) User Datagram Protocol (UDP) Transmission Control Protocol (TCP) Dynamic Host Configuration Protocol (DHCP) Client Domain Name System (DNS) Client Bootstrap Protocol (BOOTP) Trivial File Transfer Protocol (TFTP) NicheLite for LPC Leaflet (attached) Software Obtaining the Software NicheLite for LPC source code is free to NXP customers for unlimited use with NXP LPC1000, LPC2000, and LPC3000 families of microcontrollers only.Obtaining and using NicheLite for LPC is conditional upon accepting a detailed Software License Agreement (SLA). Please download and carefully read the SLA if you have not done so already: Revision History for NicheLite V1.02 (Jul 17, 2007) (attached) Contents The NicheLite for LPC software package includes: NicheTask™ cooperative multi-tasking scheduler TCP supporting InterNiche's Light Weight API with a Zero-Copy option IPv4 without fragmentation/reassembly ARP ICMP Ping TFTP NicheTool™ NicheFile VFS Mini-Sockets API Single Ethernet interface with device drivers optimized for the LPC17xx, LPC23xx/LPC24xx, and LPC32x0 TFTP client TFTP server Example applications (TFTP client, TFTP server, HTTP listener) NicheLite Reference Manual (not for redistribution) HTML-Formatted User's Guide (intended for distribution to end customers) Clearly written, comment-rich ANSI-"C" source code A header file, required at compile time, articulates the details of the source license which prohibits the end customer from distributing the source for NicheLite for LPC. End-Customer Options and Upgrades Available options and upgrades from InterNiche to NXP customers of NicheLite for LPC include: Technical Support Professional Services HTTP Server PPP SNMP v1, v2c, v3 SMTP Client (Email Alerter) NicheStack SSL POP3 Client FTP Server and Client Upgrade to Full NicheStack IPv4, IPv6, Dual Products   NicheStack HTTPServer™ (Attached) NicheStack SSL™ (Attached) NicheStack IPv4™ (Attached) Contact InterNiche for Details More Information Cortex-M0 Microcontrollers Cortex-M3 Microcontrollers Cortex-M4 Microcontrollers ARM7 Microcontrollers ARM9 Microcontrollers InterNiche Technologies, Inc. Overview Presentation (Attached) InterNiche Technologies, Inc. NicheTask Open Source OS
View full article
A block diagram of the dual core IRAM demo is shown below. Per the diagram, FreeRTOS runs on both cores with memory for the M4 core in the first 64K of IRAM. The M0 core uses the 32K of IRAM at offset 64K. The M0 and M4 signal each other via the core interrupt event mechanism. IRAM at address 0x10080000 is used for the shared memory queue. The tri-color LED is used to indicate lfe on a specific core. The red LED will blink when the M4 core is running, while the blue LED will blink when the M0 core is running. The green LED will blink at a varying rate when the M0 core is running and data has been supplied in the shared memory queue from the M4 core.
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
Introduction This page gives more detailed information on how to use the IOH libraries in custom projects when using the IAR EWARM IDE. For more general information regarding using IOH libraries in custom project or for detailed instructions for LPCXpresso and Keil, visit IOH: Getting started with IOH in custom projects. Ready-to-use examples can be found at the main I/O Handler page. Note: This guide assumes the IOH I2S library is to be added to a project, hence the 'I2S' references. For other IOH libraries, 'I2S' should be replaced with the library name. 1. Add the IOH library (ioh_*_iar.a) to the project The first step is to configure the IAR project to link against the IOH library. This can be done by simply adding the .a file to the project. 2. Add the path where the library's header file resides to the project’s include path The next step is to add the file location of the library's header file to the include path of the project. Open the project options and browse to the category 'C/C++ Compiler', then to the tab 'Preprocessor'. Add the location of the header file to the 'Additional include directories'. 3. #include the IOH header file in the source code of the application The IOH header file must be included in the source code of the project (e.g. main.c) by using the following preprocessor directive: #include "IOH_I2S.h" 4. Configure the linker to place the IOH related sections in the IOH SRAM All IOH parts have an SRAM region reserved for I/O Handler. When starting IOH, usually by calling the library's init() function, I/O Handler expects this memory region to be loaded with the IOH data provided by the IOH library. This means this data must be stored in Flash and copied to the IOH SRAM upon startup. A convenient way to do this, is by using scatter loading. With scatter loading, the linker and c-library are instructed to program certain data sections (IOH data) into Flash, and copy it to the specifed region (IOH SRAM) upon start up. This requires a linker script. The linker script can be added to the IARproject by opening the projects options and browsing to the 'Linker' category. First check the 'Override default' checkbox, then add the file location to the 'Linker configuration file' box. Following is the part of the linker script used for the LPC11U37H, responisble for placing the IOH sections in the SRAM1 region (IOH SRAM): define symbol __IOHRAM_start__ = 0x20000000; define symbol __IOHRAM_end__   = 0x200007FF; define region IOHRAM_region = mem:[from __IOHRAM_start__ to __IOHRAM_end__]; initialize by copy { section .ioh_text }; initialize by copy { section .ioh_constdata }; initialize by copy { section .ioh_data }; place in ROM_region { section .ioh_text_init }; place in ROM_region { section .ioh_constdata_init }; place in ROM_region { section .ioh_data_init }; place in IOHRAM_region { rw section .ioh_text}; place in IOHRAM_region { rw section .ioh_constdata }; place in IOHRAM_region { rw section .ioh_data }; place in IOHRAM_region { rw section .ioh_bss }; 5. Enable the IOH SRAM (SRAM1) before C-library initialization The copying of data from the 'load region' to the 'execution region' when using scatter loading (explained above) is executed by the c-library just before main() gets called. It's important that both regions are enabled when the copying is initiated. After power-on, the IOH SRAM on the LPC11E/U37H is disabled (clock disabled in the SYSAHBCLKCTRL register), so it must be enabled before the scatter loading is initiated. The right place (assuming the CMSIS standard is followed) to enable the IOH SRAM, is in the SystemInit function. SystemInit() is called just before the C-enviroment is initialized as can been seen from the following snippet from the LPC11xx IAR startup file: PUBWEAK Reset_Handler SECTION .text:CODE:REORDER(2) Reset_Handler LDR     R0, =SystemInit BLX     R0 LDR     R0, =__iar_program_start BX      R0 Therefore the SystemInit() function should contain the code for enabling the IOH SRAM block, e.g. by adding the following line to the SystemInit() function (assuming the LPC11E/U37H): LPC_SYSCON->SYSAHBCLKCTRL |= (1<<26); 6. Interact with IOH via the library's API The final step is to interact from the application with IOH. This can be done through the library's API. Each library comes with an application note explaining how to use the library and what data structures and functions are available, and with one or more application examples showing how to use the library. This application note and application example provide an easy way to get started. They can be downloaded from the main I/O Handler page.
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