This content was originally contributed to lpcware.com by Richard Man This project demonstrates how easy it is to port a commonly used open source FatFS code to the LPC4350 using SDIO and built-in SDMMC support. In the competitive embedded microcontroller market, one way a silicon vendor can differentiate its offerings from the rest is by integrating higher-function peripherals onchip. As such, it is no longer unusual to find chips with built-in LCD, USB, CAN, Ethernet, and in some instances, even hardware support for the SD/MMC memory devices. Such is the case with the NXP LPC4350. With two ARM Cortex cores and many other features, it also sports SD/MMC hardware. Without dedicated SD/MMC support, the firmware typically must use bit banging code which is timing sensitive and adds to the complexity of the code.

lpcopen. uart  #ring_buffer

lpc‌ feature‌ LCD‌ Attached doc is the LPC MCU Serial LCD controller feature introduction and application

Some processors in LPC family have EMC, which enable customer to connect external parallel SRAM, NOR flash, SDRAM, there is application which saves code in serial flash for example SPI flash or IIC flash, copy the code to SDRAM and run code in SDRAM. This is a simple code to demo how to run the code in SDRAM, the Code is developed under the SDRAM example code with SDK package, which initialize SDRAM and write data to SDRAM, read the data from SDRAM, compare whether the writing data and reading data are the same. A simple function void LED_Toggle(void) is used to toggle a LED, the API function is copied to SDRAM with the function void mem2mem(uint16_t *sourceAdd,uint16_t *destinationAdd,uint16_t length), after the function is called, an function pointer is defined and jump to the function pointer. BTW, if user would like to run code in SDRAM, the MPU module for the Cortex-M4 has to be initialized, which enable the code in SDRAM to be fetched and executed. The Demo code is developed under MCUXpresso ver10.3.1 and LPCXpresso546xx board(OM40003). after you Run code, the LED2 can toggle on LPCXpresso546xx board.. I list the main code here. All the project is attached. void mem2mem(uint16_t *sourceAdd,uint16_t *destinationAdd,uint16_t length) {     sourceAdd = (uint16_t *)((uint32_t)sourceAdd & (0xFFFFFFFE));     destinationAdd=(uint16_t *)((uint32_t)destinationAdd & 0xFFFFFFFE);     for(uint16_t i=0; i<length; i++)     {         destinationAdd[i]=sourceAdd[i];     }     __DSB();     __ISB(); } #define SDRAM_BASE_ADDR_CODE 0xa0000001 typedef void (*functionPointer)(void); //The PC value must be an odd value although the code address is an even //value void runCodeInSDRAM(void) {     ((functionPointer)SDRAM_BASE_ADDR_CODE)(); } void LED_Toggle(void) {     while(1)     {         delay_1();         GPIO->NOT[3]|=1<<3;     } } void MPU_Init(void) {     //disable MPU     MPU->CTRL=0x00;     //Region0: default region 0     MPU->RBAR=0x00000010;     MPU->RASR=0x1004003f;     //Region 1:     //set up flash, ROM, SRAM ... as region 1     //# 0x00000000 - 0x3FFFFFFF     MPU->RBAR=0x00000011;     MPU->RASR=0x0306E23b;     //Region 2:     //set up peripheral device     //# 0x40000000 - 0x400FFFFF     MPU->RBAR=0x40000012;     MPU->RASR=0x13050033;     //Region 3:     //set up chip select and device     //# 0x80000000 - 0x9000FFFF     MPU->RBAR=0x80000013;     MPU->RASR=0x1305001f;     //Region 4:     //set up SDRAM     //# # 0xA0000000 - 0xA0FFFFFF     MPU->RBAR=0xa0000014;     MPU->RASR=0x0307002f;     //Region 5:     //set up Cortex-M4 Private Peripheral Bus     //# 0xE0000000 - 0xE00FFFFF     MPU->RBAR=0xe0000015;     MPU->RASR=0x13040027;     //Region 6:     //set up Not used     //# 0xE0000000 - 0xE00FFFFF     MPU->RBAR=0xe0000016;     MPU->RASR=0x00000000;     //Region 7:     //set up stack     //#     MPU->RBAR=0x1000E017;     MPU->RASR=0x10060009;     //enable MPU     MPU->CTRL=0x01; } int main(void) {     uint32_t index;     uint32_t *sdram = (uint32_t *)SDRAM_BASE_ADDR; /* SDRAM start address. */     /* Hardware Initialization */     CLOCK_EnableClock(kCLOCK_InputMux);     /* attach 12 MHz clock to FLEXCOMM0 (debug console) */     CLOCK_AttachClk(BOARD_DEBUG_UART_CLK_ATTACH);     BOARD_InitPins();     BOARD_BootClockFROHF96M();     BOARD_InitDebugConsole();     LEDInit();     //LED_Toggle();     BOARD_InitSDRAM();     MPU_Init();     mem2mem((uint16_t *)LED_Toggle,(uint16_t *)SDRAM_BASE_ADDR_CODE,400);    // LED_Toggle();     runCodeInSDRAM(); }

View Webinar Recording

View Webinar Recording

This documet is an introduction about TrustZone on the LPC55S6x devices. LPC55S6x MCU platform and general-purpose blocks The LPC55S69 has one 100-MHz Cortex-M33 core with TrustZone, MPU, FPU, and SIMD and another 100-MHz Cortex-M33 without security features enable. Lets remark that the LPC55Sxx family has another LPC55S66 that only implements a single 100-MHz core. There are two coprocessors on core 0, a DSP accelerator called PowerQuad, and a crypto engine called CASPER. The core platform has a multilayer bus matrix that allows simultaneous execution from both cores and parallel access of the other masters to peripherals and memories. The memory on chip includes up to 640 KB of Flash, up to 320 KB of RAM, and 128 KB of ROM. Timers include 5 - 32-bit timers, a SCTimer/PWM, a multi-rate timer, a windowed watchdog timer, Real Time Clock (RTC), and a micro timer. Each core has its own systick timer. Communication interfaces include a USB high-speed with on-chip HS PHY, a USB full-speed that can run crystal-less, two SDIO interfaces to support WIFI and SD cards at the same time, 1 high-speed SPI with up to 50-MHz clock rate, and 8 Flexcomms with support of up to 8 SPI, I2C, UART, or 4 I2S. The analog system includes a 16-channel 16-bit ADC that samples at 1 MSPS, an analog comparator, 16-channel capacitive touch controller, and a temperature sensor. Other modules include a programmable logic unit, a buck DC-DC converter, operating voltage from 1.71 to 3.6 V over a temperature range from -40 to 105 °C. What is TrustZone? In recent years, the Internet of Things (IoT) has become a hot topic for embedded system developers. IoT system products have become more complex, and better solutions are needed to ensure system security. ARM® TrustZone® technology is a System on Chip (SoC) and CPU system-wide approach to security. The TrustZone® for ARMv8-M security extension is optimized for ultra-low power embedded applications. It enables multiple software security domains that restrict access to secure memory and I/O to trusted software only. TrustZone® for ARMv8-M: Preserves low interrupt latencies for both secure and non-secure domains Does not impose code overhead, cycle overhead or the complexity of a virtualization based solution Introduces efficient instructions for calls to the secure domain with minimal overhead TrustZone® is a technology available in Cortex M23 and Cortex M33. TrustZone® provides the means to implement separation and access control to isolate trusted software and resources to reduce the attack surface of critical components. The created trusted firmware can protect trusted operations and is ideal to store and run the critical security services. The code should also protect trusted hardware to augment and fortify the trusted software. This includes the modules for hardware assists for cryptographic accelerators, random number generators, and secure storage. Best practices demand that that this code be small, well-reviewed code with provisions of security services. The LPC55S66 and LPC55S69 have implemented core 0 as a Cortex-M33 with full TEE and TrustZone® support enabled. The LPC55S69 has a second Cortex-M33 (core 1) that does not implement the secure environment with TZ. Isolation is just the foundation. Security is about layers of protection, adding in further hardware and software to create more layers. Features of TrustZone® technology: Allows user to divide memory map into Secure and Non-Secure regions Allows debug to be blocked for Secure code/data when not authenticated CPU includes Security Attribution Unit (SAU) as well as a duplication of NVIC, MPU, SYSTICK, core control registers etc. such that Secure/Non-Secure codes can have access to their own allocated resources Stack management expands from two stack pointers in original Cortex-M (Main Stack Pointer (MSP) and Process Stack Pointer (PSP)) to four, providing the above pair individually to both Secure and Non-Secure Introduces the concept of Secure Gateway opcode to allow secure code to define a strict set of entry points into it from Non-secure code Secure and non-secure memory TrustZone® technology divides the system into two states, safe (S) and non-secure (NS), and can switch between the two states through corresponding commands. The CPU states can be secure privilege, secure non-privilege, privilege (Handler), or non-privilege (Thread). The Secure memory space is further divided into two types: Secure and Non-secure Callable(NSC). Below are the feature/properties of Trustzone memory regions ( S, NS, NSC 😞 Secure (S) - For Secure code/data − Secure data can only be read by secure code − Secure code can only be executed by CPU in secure mode Non-Secure (NS) – For non-Secure code/data − NS Data can be accessed by both secure state and non-secure state CPU − Cannot be executed by Secure code Non-Secure Callable (NSC) − This is a special region for NS code to branch into and execute a Secure Gateway (SG) opcode. Attribution Units Combination of Security SAU and IDAU assign a specific security attribute  (S, NS, or NSC) to a specific address from the CPU0. Device Attribution Unit (DAU) connects to CPU0 via IDAU interface as show the following Figure. Access from CPU0, dependent on its security status and the resultant security attribute set by the IDAU and SAU, is then compared by the secure AHB Controller to a specific checker which marks various access policies for memory and peripherals. All addresses are either secure or non-secure. The SAU inside of the ARMv8-M works in conjunction with the MPUs. There are 8 SAU regions supported by LPC55S69. Secure and non-secure code runs on a single CPU for efficient embedded implementation. A CPU in a non-secure state can only execute from non-secure program memory. A CPU in a non-secure state can access data from both NS memory only. For the secure, trusted code, there is a new secure stack pointer and stack-limit checking. There are separate Memory Protection Units (MPUs) for S and NS regions and private SysTick timers for each state. The secure side can configure the target domain of interrupts. The NXP IDAU (Implementation specific Device Attribution Unit) implementation of ARM TrustZone for core0 involves using address bit 28 to divide the address space into potential secure and non-secure regions. Address bit 28 is not decoded in memory access hardware, so each physical location appears in two places on whatever bus they are located on. Other hardware determines which kinds of accesses (including non-secure callable) are allowed for any address.  The IDAU is a simple design using address bit 28 to allow aliasing of the memories in two locations. If address bit 28 is = 0 the memory is Non-Secure. If address bit 28 = 1 the memory is Secure. The SAU allows 8 memory regions and allow the user to override the IDAU’s fixed Map, to define the non-secure regions. By default, all memory is set to secure. At least one ASU descriptor should be used to make IDAU effective. If either IDAU or SAU marks a region, then that region is secure. NSC area can be defined in NS region of the IDAU. For example a designer could use bit [28] of the address to define if a memory is Secure or Non-secure, resulting in the following example memory map. Simple IDAU, without creating a critical timing path. (CM33 does allows little for IDAU function) Addresses 0x0000_0000 to 0x1FFF_FFFF are NS, Addresses 0x2000_0000 to 0xFFFF_FFFF If Address Bit_28 = 0  Non-Secure If Address Bit_28 = 1  Secure All peripherals and memories are aliased at two locations. The SAU define region numbers for each of the memory regions. The region numbers are 8-bit, and are used by the Test Target(TT) instruction to allow software to determine access permissions and security attribute of objects in memory. The number of regions that are included in the SAU can be configured to be either 0, 4 or 8. Note: When programming the SAU Non-secure regions, you must ensure that Secure data and code is not exposed to Non-secure applications. Security state changes The system boots in secure state and can change security states using branches as summarized in the following Figure. Transitions from secure to non-secure state can be initiated by software through the use of the BXNS and BLXNS instructions that have the Least Significant Bit (LSB) of the target address unset. Note: The M profile architecture does not support the A32 instruction set. This allows the LSB of an address to denote the security state. Transitions from non-secure to secure state can be initiated by software in two ways: A branch to a secure gateway. A branch to the reserved value FNC_RETURN. A secure gateway is an occurrence of the Secure Gateway instruction (SG) in  the Non-Secure Callable (NSC) region. When branching to a secure gateway from non-secure state, the SG instruction switches to the secure state and clears the LSB of the return address in lr. In any other situation the SG instruction does not change the security state or modify the return address. A branch to the reserved value FNC_RETURN causes the hardware to switch to secure state, read an address from the top of the secure stack, and branch to that address. The reserved value FNC_RETURN is written to lr when executing the BLXNS instruction. Security state transitions can be caused by hardware through the handling of interrupts. Those transitions are transparent to software and are ignored in the remainder of this document. The TT instruction The ARMv8-M architecture introduces the Test Target instruction (TT). The TT instruction takes a memory address and returns the configuration of the Memory Protection Unit (MPU) at that address. An optional T flag controls whether the permissions for the privileged or the unprivileged execution mode are returned. When executed in the secure state the result of this instruction is extended to return the Security Attribution Unit (SAU) and Implementation Defined Attribution Unit (IDAU) configurations at the specific address. The MPU is banked between the two security states. The optional A flag makes the TT instruction read the MPU of the non-secure state when the TT instruction is executed from the secure state. The TT instruction is used to check the access permissions that different security states and privilege levels have on memory at a specified address. You can find more useful information about ARM® TrustZone®, in the following links: https://developer.arm.com/ip-products/security-ip/trustzone https://www.nxp.com/docs/en/application-note/AN12278.pdf http://www.keil.com/appnotes/files/apnt_291.pdf  http://infocenter.arm.com/help/topic/com.arm.doc.ecm0359818/ECM0359818_armv8m_security_extensions_reqs_on_dev_tools_1_0.pdf

The OM13043 kit described below is no longer available (the LPC1227 and LPC1100XL devices are still available). This material is provided for reference materials, but KNX software is still available from Weinzierl Engineering. Building automation systems based on KNX communication protocols Communication is becoming essential in complex buildings. For this reason, NXP cooperates with Weinzierl Engineering to offer dedicated components to realize KNX based systems. A professional version of the KNX system B stack is now available on LPC Microcontrollers to allow a jump start with KNX development. System notes LPC1100XL and LPC1200 series microcontrollers: Based on the highly energy-efficient ARM® Cortex™-M0 processor Dramatically lower the cost per KNX node in home and building automation networks Cortex-M0 architecture ideally suited for low-complexity end nodes Include up to 128 KB Flash and 8 KB SRAM, and offer highly configurable peripherals Can be powered directly from the DC-DC converter of the KNX twisted-pair transceivers, making bus-powered devices easy to implement With performance levels up to 45 DMIPS, a single MCU delivers the resources required to run a KNX System B stack (up to 65535 nodes), with enough bandwidth available for the end application Reduced time to market – full professional stack available from partners with flexible license models A certified implementation of the KNX System B is available for the LPC1200 from Weinzierl Engineering  Implementation example (OM13042 demo board): Available with the NXP LPC1227 microcontroller and ON Semiconductor’s NCN5120 transceiver, suitable for use in KNX twisted pair networks (KNX TP1-256) Specifically designed to simplify design process with a ready-to-implement, energy-efficient KNX TP solution for applications such as lighting switches and control, HVAC control, shutters and occupancy detection Improves power efficiency, reduces development costs, accelerates time to market for KNX applications on ARM Cortex-M0 Application Note AN11231 is available here More information on KNX:  www.knx.org KNX TP Stack System B from Weinzierl Engineering - The new dimension of KNX development Each KNX device is based on a device model, that specifies both the management procedure (that is, how the device is configured via the bus) and identifies the resources available to the device (for example, the maximum size of the connection table). System B (mask version 07B0) is a new device model that has been defined specifically for the implementation of complex KNX devices. The main advantage lies in the number of available communication objects. While previous devices models were limited to 255 objects or less, System B theoretically permits up to 65,535 communication objects. To achieve this, the formats of the communication tables (group address, association and group object tables) have been redefined in the KNX specification for System B. System B devices can update their communication objects at system startup. This function is called Read-On-Init and can be activated individually for each object. Once the application is started the system software sends group read-value services independent from the application task. These services are scheduled by the stack to ensure that the bus is not excessively loaded at startup. System B also offers a greatly increased address space. The configuration data (application, parameters and tables) can be loaded into a range of up to 1 MB (20-bit addressing) via the bus (using memory services). To access system parameters, additional properties in the interface objects of the system have been introduced. System B is supported by the ETS manufacturer tool MT4, by ETS3 andETS4. Implementation for optimal performance Weinzierl Engineering as a KNX system supplier offers a new implementation for KNX System B, specifically targeted at complex devices with a 32-bit architecture like the Cortex M0 from NXP. It includes a complete implementation of the specification and is optimized to ensure high performance for all application sizes. A major consideration in the development of System B is the timely (real-time) processing of the large association table, which contains the assignment of group addresses to the communication objects and vice versa. It is loaded by ETS and is not sorted. For a table length of more than a thousand entries, linear search algorithms are not effective and therefore additional look-up tables have been introduced that allow quick access via indices. The processing of the communication objects has also been accelerated and a linear search through all objects is avoided with the use of additional buffers. Although these design features may require additional memory, they facilitate low CPU clock speeds. Higher performance is achieved at the same frequency with than with previous implementations with considerably reduced KNX resources. The System B implementation from Weinzierl Engineering uses a virtual address space that is resolved at the driver level and mapped to the corresponding physical storage areas. This means that applications are easily ported to different platforms. As for all Weinzierl's stack implementations, the focus is to ensure ease of application development. The application interface has been largely maintained and is accessible via comprehensive API functions. It is possible to implement either internal or external applications. An internal application is bundled together with the stack in the device and the ETS simply has to load the parameters and tables, which ensures quick download times. An external application is loaded by the ETS along with the parameters and tables. The stack also supports additional interface objects (user properties). These objects can be used, for example, to set device parameters using point-to-point communication on the bus. ETS parameters can also be realized with Properties. For the creation of the product data base with ETS MT4 (Manufacturer Tool) our bus monitor and KNX development tool Net'n Node has been extended with a new export function. After importing the data of the software project it directly generates an XML file that contains all the storage areas, load controls and binary application data. This XML file can be imported directly into the MT4 solution.

LPC4088 Closed Payment Loop Demo - Running the demo Directly after programming the FLASH has finished, or after power-up, the demo is ready to use. The following screen will be presented: In order to use the demo, first the Mifare Classic card must be initialized. This can be done by holding the card in-range of the RFID antenna and pushing the center button of the Embedded Artists base-board. If successful, a confirmation message is shown for half a second. Next, credit must be added to the card. This is done by again holding the card in-range of the RFID antenna, but now pushing the joystick to the top-position (towards the edge of the board). Every time the joystick is pushed to the top-position, $10 will be added to the card. If successful, a confirmation message is shown for half a second after pressing the joystick. The credit can be queried by pressing the "Query Card" button. Now that the card is initialized and charged, products can be purchased. By pushing the product-buttons in the 3x3 grid, products can be selected. Every time a product is selected, it is added to the listbox and the total cost is updated. Upon pressing "Checkout", the credit available on the card is read-in, the total cost is subtracted and the new credit is written back to the card. A confirmation of this action will be shown.

#lpc5410x‌ #fifo‌ #timeout‌

#lpc5410x‌ #fifo‌ #timeout‌

This documents describes how to use this tool in order to generate the routing and muxing for pins. This tool is available as an online WEB application https://mcuxpresso.nxp.com Pins Tool Overview The Pins Tool is an easy-to-use way to configure the pins of the device. The Pins Tool software enables you to create, inspect, change, and modify any aspect of the pin configuration and muxing of the device. This document introduces you to the Pins Tool. It describes the basic components of the tool and lists the steps to configure and use the tool to configure the pins. This tool is provided as an online WEB application. You need to generate a downloadable MCUXpresso SDK v.2 package. The below link shows the steps for do that. Generating a downloadable MCUXpresso SDK v.2 package  User interface The Pins Tool consists of several views. Using the Pins Tool The Pins Tool is designed to configure routing of signals from peripherals either to pins or to internal signals. To define routing path, first select a peripheral, then select the signal, and finally select the pin. 1. Select a peripheral for example GPIO. The following image illustrates the filtering controls in the Pins view. 2.  Route the selected Signal to the desired pin. It is possible to easily identify routed pins/peripherals in the package using highlighting. By default, the current selection (pin/peripheral) is highlighted in the package view. • Red indicates that the pin has an error. • Green indicates that the pin is muxed or used. • Light grey indicates that the pin is available for mux, but is not muxed or used. • Yellow border around the pin such that the other color is still visible indicates that the pin is selected. For example, by peripheral or by pin. 3. Select one of non-conflicting/available pins. Once you have selected Peripheral, Signal, and Route to, the pin configuration is done. Later, it is also possible to configure the pin electrical features. Use the table drop down menu to configure the pin. To configure pins, start from left to right – select the peripheral first, then select required signal, and finally select the routed pin. The italic value indicates that the value is not configured and it shows the after-reset value and no code is generated, so the configuration relies on the after reset value or the values configured from the different functions. Code generation The tool generates source code that can be incorporated into an application to initialize pins routing. The source code is generated automatically on change or can be generated manually by selecting the main menu Pins > Generate Now. The generated code is shown in the Sources tab on the right window. It shows all generated files and each file has its own tab. It is also possible to copy and paste the generated code into the source files. The view generates code for each function. In addition, it is possible to Export generated source using the Export option. 1. Select Pins > Export 2. Click Next. 3. Select the name of the zip file and click Finish. Your download should automatically begin.  Enjoy!!   Related links: Introducing MCUXpresso SDK v.2 for LPC54xxx Series  Generating a downloadable MCUXpresso SDK v.2 package  MCUXpresso Config Tools is now available!   How to start with SDK v.2.0 for LPC5411x using LPCXpresso IDE 

Today's Data Acquisition Applications require separate ICs for input, processing, and output. With the new LPC4370, designers have a complete data acquisition solution on a single chip. With the release of NXP’s new LPC4370 Cortex-M4F microcontroller, we wanted to provide engineers with the tools necessary to evaluate its high-performance signal processing capabilities (up to 204 MHz) and its host of advanced features and peripherals including the 12-bit ADC at 80 Msps with up to six channels.   The result is a new product from Embedded Artists, named LabTool.  LabTool is as an add-on board to NXP’s LPC-Link 2 debugger and demoboard platform.  The LabTool includes a hardware daughter board and software running on the PC that enables the Link2 to be used as a logic analyzer, oscilloscope, and signal generator. It is designed around NXP’s new LPC4370 microcontroller, and the hardware can serve as a development platform for this MCU.   LPC4370 and LabTool Key Components Follow the URLs in the table to find more information on the product and its key components. LPC4370 The LPC4370, ARM Cortex-M4F based microcontrollers, are complete data acquisition solutions on a single chip. The LPC4370 provide the fast digital and analog inputs, the high performance processing capabilities, and the hi-speed output needed for data acquisition applications. Running up to 204MHz, the ARM Cortex-M4F of the LPC4370 is the industry’s fastest Cortex-M microcontroller. The Cortex-M4F is a next generation 32-bit core that offers system enhancements such as low power consumption, enhanced debug features, and a high level of support block integration. Download the LPC4370 documentation: LPC4370 BGA256 Product Information Page LPC4370 BGA100 Product Information Page LPC4370 User Manual and Data Sheet LPC4300 Series Leaflet LPC-Link2 LPC-Link 2 is an extensible, stand-alone debug probe that can be configured to support various development tools and IDEs using a variety of different downloadable firmware images. It can also be used as an evaluation board in its own right for the NXP LPC4370 triple core MCU. And through the use of an add-on board from Embedded Artists, it can be used as an oscilloscope or logic analyzer! For more information on the Link 2, view our NXP.com page. LabTool LabTool can be purchased as a kit that includes the Link2 main board plus the add-on board, or the two can be purchased separately.  A connector with 26 probe wires is included, and is the only accessory required for using the tool.  The probes feature a 2.54mm pigtail end, for easily connecting to headers and jumpers on a target platform.  A set of compatible microgrippers may also be useful, but must be purchased separately. Purchase LabTool, download documentation and the GUI at Embedded Artists product page.   LabTool also available for purchase at: Watch the video here.   LabTool Features   The LabTool consists of both a hardware platform and a software GUI, which combine together in providing the following set of features that are commonly used by electronic designers during bench debugging.  A standard 5.0V supply from your high-speed USB2.0 connector provides the power needed to operate the board, as well as the high-speed communication channel for the data stream.   Digital Channels 10 channel logic analyzer supporting 100MHz (2ch), 80Mhz (4ch), 50MHz (8ch), 20MHz (10ch) Selectable edge-sensitive and level-sensitive triggers give you flexibility in how the signal is displayed. 11 channel digital signal generator up to 80Mhz, at 3.3 volts logic level. Included with the digital interface are three protocol analyzers.  You can monitor SPI, I2C and UART with a built-in interpreter that shows the timing of clock and data transfers in the GUI. Demonstration signals are provided already on the board, by means of an LPC812 microcontroller.  This devices generates heartbeat PWM, four digital counters (at 750KHz, 1.5MHz, 3.0Mhz and 6.0MHz), plus SPI, I2C and UART data streams.  These signals can be used for quickly verifying the tools is up and running, and provides reference signals for comparing to your own design when measured by the LabTool.   Analog Channels   2 channel oscilloscope sampling at 80Msps (1ch), 40MHz (2ch), with 6MHz bandwidth rating.  The voltage range that can be sampled is a very wide range at +/- 25 volts.  Input impedance is 1Mohm. 2 channel analog output generation at 40KHz bandwidth, at +/- 5 volts.  Three built-in waveform generators support sine, square and triangle waveforms.   GUI   LabTool comes with a feature rich software interfaced developed by Embedded Artists.  The GUI gives users the capability to manage the digital and analog channels through: Dialogs for selecting digital and analog inputs channels One-shot and continuous sampling Sorting and moving of signals Applying application-specific signal names Saving settings in a project file Exporting collected data to .csv formatted files Appling SPI, I2C or UART protocol analyzers to selected channels Using four cursors to measure and interpret waveforms     Open Source Environment   The GUI is developed using Qt framework, and can be provided as open source. Source code for the firmware operating on the LPC4370 is also planned to be released for use among the community of NXP users.  Developers are encouraged to use this firmware as a starting point for creating exciting new applications based on LPC4370! Getting Started   A comprehensive user guide for the LabTool is available from Embedded Artists at the link given above. Tips for getting started:   Refer to the user guide and notes on Embedded Artists web site for the most recent instructions.  Here are some tips that have helped our testers and expert industry users to get started smoothly.   Install the GUI software first.  USB drivers (needed at step #2 below) are copied to the installation folder during this step. Attach the LabTool add-on board to the Link2 (see image below for proper orientation). Driver installation may take several minutes, and is accomplished in two steps.   When the hardware is first connected to a USB port, the driver for the Link2 must be installed.  This driver is included with the LPC-Link2 Configuration Tool.  The device manager shows the hardware is enumerated as “LPC Device”. Once the Link2 driver is loaded, the next step allows the LabTool GUI to be started.  The first time the GUI runs, it will detect the LabTool hardware, and will load an additional driver.  This driver is located in a sub-folder from the location where the LabTool software package was installed.  The device manager shows the hardware is now enumerated as “NXP LabTool”   Once the GUI is running, check that “LabTool Device” is displayed in the section marked “Selected device” in the diagram above. The probe bundle has each wire function labeled on the silk screen of the PCB.  Check these carefully to find cable D0, and connect it to the demonstration signal  labeled “PWM_LED” on the header at the bottom right corner of the board.  In the GUI, choose “Add Signal” and select D0 as an input channel; press OK.  Set a falling edge trigger and a sample rate of 2MHz.  Choose continuous sampling, and view the results in the waveform view.  It’s that simple!   Correct Orientation   Correct orientation is required.  Be sure the expansion headers on the Link2 are aligned properly to the connectors on the LabTool add-on board.  The USB port is located at the end opposite from the BNC connectors.     Industry Experts and NXP Testers   We asked leading experts in the embedded community to test the LPC4370 and LabTool, create some test code, and let us know what they thought of the whole process.  Below are their evaluations:   Industry Experts   Kevin Townsend has been working with LPC microcontrollers since the ARM7 LPC2000 products were released. He specializes in ARM Cortex-M0/M3/M4 design and development with interest in low power and wireless sensors. He is active in the open source HW world as Lead Engineer at Adafruit Industries. Kevin tested the LPC4370 and wrote a review on his blog site, www.microbuilder.eu. To read his insightful commentary follow this link.   Bob Boys is a Product Manager for Keil MDK and ARM DS-5 tools at ARM with multiple years of experience in the industry. He holds a Masters in Information Sciences and has worked with a variety of hardware and software platforms around the ARM Cortex family of products. Bob decided to test out the oscilliscope feature of the LabTool. See his review below.   Dirceu Rodriguez, Jr. is a computer engineer with a master's degree in electrical engineering. As an independent consultant, he tests new products with particular interest in the areas of wireless sensor networks, ARM processors, DSP, motor control, and medical applications. (Review coming soon)   Massimo Manca has 20+ years of experience in the industry. He has worked on a variety of applications with more than 30 different microcontroller families. Massimo gave the LabTool and Link2 a thorough testing on all parts.  Initial comments are provided below, with an additional review coming soon.   NXP Testers NXP Application Engineers have tested the LPC4370 and LabTool for themselves.  Their feedback and use cases are shown below.     Using the SPI Protocol Analyzer     Using LabTool to evaluate Rotary Encoder and QEI peripheral     Investigating I2C/SMBus issue using LabTool     Comparing the LabTool to a commercially available signal analyzer   Evaluations and Reports Kevin Townsend hosts a blog on his microbuilder.eu site. Read his insightful commentary here.   Bob Boys from ARM, Ltd. wrote:   I tested the scope part as this is what I am most interested in.  LabTool in this respect worked quite well compared to other USB scopes I have used that cost mush more.  I tested it on a two node CAN network and the SWO Serial Wire Output: both on a Keil MCB1700 (LPC1768) board.   I liked these things: 1)    Easy to change from neg/pos slope or no trigger. 2)    Changing the trigger point was very easy although I liked using the no trigger setting better to initially get a waveform going. 3)    Determining the timing was easy and surprisingly accurate.  At first I was getting very bad frequencies but after I calibrated the LabTool per the instruction it was fine. 4)    Setting the cursors was easy – but see point 5 below. 5)    The waveform faithfulness compared to my HP 100 mHZ scope was quite good. 6)    Installing the software was easy although I had some initial trouble with the USB drivers – it could detect it and under device the labtool Device was grayed out.  I had to uninstall the previous LPC-Link 2 USB drivers (which had worked OK for me) – it showed it was not installed correctly or something like that -  it had a small yellow icon in Device manager.  Now it works fine. 7)    Single shot and continuous collection works easier than on my HP.   I thought these could be improved: 1)    The scope selection is called Analog.  I was confused – why not just label it scope ? 2)    I had some difficulty getting a waveform displayed sometimes – I had to fiddle with it. 3)    I was not able to erase a waveform so sometimes I didn’t know if I had  a new one or nothing or ????  Making this part easier to use might be worth it. 4)    I could not make the waveform bigger or shift it up or down (position). 5)    When I clicked on a cursor icon to bring it up into the screen – the waveform shifted and it looked like (to me anyway) to have disappeared.  It was there – It took me a while to figure this out. 6)    CAN is a differential signal but it seemed to work.  A differential input would be nice.  So would a CAN Analyzer. 7)    I had a hard time getting the “DC” to work – “AC” was always better and easier. 😎    The ability to change the waveform colour might be a good idea.   Following are the results of two tests.   CAN on one channel: 1)    500 kHz is correct ! 2)    The waveform (at 80 MHz) is good – the overshoots are not visible on the HP but I didn’t adjust the tiny capacitor screws on the LabTool.  There are more of the resolution errors shown on the rise and fall edge than my HP – but HP still has some.  Not a big deal. Here is the CAN frame using two channels:  Even though I had to reduce the sampling freq to 40 mHz – it still looks good.   The ability to move the waveforms vertically (and maybe a polarity switch) would be nice.     SWO: Very often customers must measure the frequency on the SWO pin if they can’t get the Serial Wire Viewer (SWV) working and they do not know what their CPU clock is. A scope makes this easy and – LabTool did very good – I think sometimes the SWO pin can go up to 1 mHz and more – but this example at 1.25 worked fine. 1.25MHz as shown here is correct ! I compared all these waveforms to my HP and LabTool did quite well. Massimo Manca wrote:   After some hours of test my feeling is that the digital part works quite well, the I2C, SPI and UART interpreters are useful and well designed. Should be very interesting to have also a CAN interpreter and a 1-Wire interpreter.   Another thing should be useful is to define the priority of the triggers on the digital signals. I mean that should be useful for instance to define the trigger on the UART - D0 line with the highest priority so the other signals will be captured only it is already captured on its trigger front.   I should need to go back to my lab to test better the analog inputs. My feeling is that the signal is not perfect due to some interference by my laptop. Should be interesting to connect a USB isolator between the boards and the PC to see what changes.   The next step will be to test the board freely always using the demo signals without following the example list. I will provide update with the results.   Using the SPI Protocol Analyzer   Lately I’ve been working with one of NXP’s solution kits.  This kit includes an LPC812 Xpresso board and a daughterboard with the SEN300 sensor.  The sensor measures temperature, humidity and light.  It interfaces the microcontroller through a 4-wire SPI bus (SCK, MISO, MOSI, CS) running at 300kHz.   Considering that an end user of this solution kit may want to add another node on the SPI bus, it should be necessary to increase the communication rate from 300kHz to a higher speed, and allow for transfers to/from the additional device using the same SPI peripheral.  Types of SPI devices that could be considered are a simple LCD for displaying the sensor readings, or an EEPROM for data logging.   After I selected new dividers for the SPI master clock to increase the clock rate to 3MHz, the communication interface broke down.  I setup the LabTool digital interfaces D0 to D3 and configured the SPI protocol analyzer to use these for the corresponding SPI signals.  Following are some screen shots and the conclusion of the problem.   Normally the communication seemed to be occuring just fine.  I noticed that the chip select signal (Digital 3) was active low outside the boundaries of the waveform view in the LabTool GUI. From time to time, actually more often than not, the SPI analyzer could not interpret the transfer data, and showed “Frame Error” was occurring.   By changing the trigger to the rising edge of the chip select, I could see this occurring more frequently.  At that time, the chip select signal was momentarily toggling high/idle and then low/active in the middle of a data transfer.   I began stepping through the code to find the routines that set and cleared the state of the chip select (a simple digital output port).   I found that the routine that handles the SPI transmit/receive buffers could get out of sync with the function controlling the chip select output, and cause message transfers to overlap.  By adding some simple logic to ensure the chip select was not idled before the SPI buffers were serviced, the problem went away.  Here is a screen shot of a good SPI transfer at the higher SCK rate.   Using LabTool and the SPI protocol analyzer feature, I was able to identify the problem in the communication interface, and then use a debugger to finish checking the root cause.   Using LabTool to evaluate Rotary Encoder and QEI peripheral   Motor control applications often use the feedback from a rotary encoder in a closed loop control system.  The LPC4370 microcontroller includes a QEI peripheral (Quadrature Encoder Interface) that decodes these signals directly.  By monitoring both the number of pulses and the relative phase of the two signals, you can track the position, direction of rotation, and velocity.  In this example, we’ve measured the QEI signal sequence with LabTool.  The type of Rotary Encoder used in this project is SXA-4EG05E1024BM with 1024 pulses per round.   The encoder ouputs A,B and Zero terms. So we connect the encoder with LabTool through DIO0~DIO2. LabTool should also be connected with the Encoder’s gound pin to ensure they share a common gound.  Use one of the available grounding probes on the 26-pos connector (e.g. probe #4), to make this connection.   DIO0 -> A Term   DIO1-> B Term   DIO2-> Zero   Open the LabTool application program on your PC, and connect the LabTool using the USB connection. The GUI will show that LabTool is connected when the text "LabTool Device" changes from red to black text.  Now, you can click the “Add Signal” button and choose D0, D1 & D2 digital signals as below picture shows. We’ll rotate the Encoder by hand, so we set the “Sample Rate” as 100kHz.   Set the D2 Digital capture on rising edge.   Click the “Capture->Continuous” or button to start sampling the digital input channels.  When we rotate the Encoder, the signal capture below is displayed with LabTool. We can move the triggers C1&C2, C3&C4 to measure the signal’s frequency and duty cycle.   If we want to measure a whole cycle from the Encoder, we can set the “Sample Rate” as 50Mhz, then rotate the Encoder and capture the entire waveform shown next. LabTool's logic analyzer feature is very powerful and useful for motor control applications measurng the feedback from a rotary encoder.   Investigating I2C/SMBus issue using LabTool   One of our customers is designing-in the NXP Microcontroller in a SAS (Serially Attached SCSI) Server system. This controller is used to manage the overall backplane activities and interfaces to the host SAS Controller on SMBUS/I2C Bus. The customer was facing major issue of I2C Bus hanging.  As such, it was difficult to diagnose the issue as there were multiple slave devices on the bus. Coincidently, we had this LabTool lying around and I thought of using it in debugging the issue. Initially, I isolated this controller from the I2C bus and hooked it up to another I2C Master. While monitoring the bus activity on the LabTool’s I2C Analyzer, apparently the overall communication was just fine as shown below.   On a closer look, I noticed that the clock (SCL) was getting stretched a bit at times, but nothing unusual. I then connected this controller back in the system and monitored the I2C bus activity on I2C Analyzer again. And no surprise, the bus hanging problem was getting reproduced as seen in the capture below. After the clock stretching interval, the clock (D2=SCL) line was holding it’s status as low and data (D1=SDA) was high. It was clear that the problem appears only when there are multiple slaves connected to a SMBUS/I2C Bus Master. It gave me some direction to think and investigate more on similar lines. Gone through the details of SMBUS/I2C peripheral on SAS Controller and as usual googled for I2C issues with multiple slaves.  Finally got a clue while going through the minute details of SMBus specifications. Though it’s normal to use I2C slaves/devices with SMBus master and vice a versa, there are subtle differences in the specifications. The most vital difference is the Timeout and (as a consequence of timeout) minimum clock speed. There’s no time out in I2C specifications, any device can stretch the Clock as long as it wants. While the SMBus clearly specifies the time out of 35msec, where slave devices resets their interfaces whenever Clock goes low for longer than the timeout. Use of such timeout also dictates a minimum speed for the clock, because it can never go static. Thus, the SMBus has a minimum-clock-speed specification of 10kHz.   To comply with the SMBus specifications Slave devices should have this time out implemented. I then added a small piece of code to generate this timeout using one of the available timers and that resolved the issue. Thanks to the LabTool!   Comparing the LabTool to a commercially available signal analyzer   There are three key features of LabTool that are useful to any developer:   80MHz sample rate using digital inputs D0 to D3 and up to 60MHz for one Analog Input. You can analyze any UART, SPI or I2C communication. You have 4 cursors to measure your signals.   Here is a comparison versus another USB-hosted signal analyzer.  We will call it "AnalyzerB" in this article.   Features and Price: Regarding AnalyzerB, the cheaper option is the product SX at $169.0 USD, it has only 8 digital input/output with a maximum sample rate of 24MHz. The most comparable product will be the AX product with a pricing of $795 USD with also 8 digital input/output with 2 analog oscilloscope inputs but you can capture maximum at 24Msps and only one analog input at any time. The AX product also can analyze CAN, PS/2, SM bus and 1-Wire communication. These options could be added easily to the PC software.   So, the pricing of $129.00 USD for the NXP LabTool is a very good pricing and with the source code available you won't have any limit to customize or improve the LabTool.   Using the Tools: I did a zoom in the PWM signals in order to get a more detail measurement and I will compare these signals measurements with the AnalyzerB tool.     D7 is 2MHz D8 is between 3.33MHz and 5MHz D9 is between 3.33MHz and 2.5MHz D10 is between 1.42MHz and 1.66MHz I had these measurements because the sample rate is at 10MHz and LabTool is using the upper channels. Now I did a measurement using AnalyzerB tool.  It couldn’t read the 12MHz signal (channel 0); the sample rate is at 12MSPS. I had to increase to 24MSPS (MAX) in order to be able to measure the 12MHz signal. The frequency measurement in each signal was exactly 1.5MHz channel 3, 3MHz channel 2, 6MHz channel 1 and 12MHz channel 0 without any variation.   Now, using the LabTool I change the 4 PWM signals to channels 0 to 3 and increase the sample rate up to 100MHz. I had the following:   The frequency in the signals is: D0 is 12.5MHz and 10MHz D1 is 6.25MHz and 5.55MHz D2 is 2.94MHz and 3.12MHz D3 is 1.51MHz and 1.47MHz   The AnalyzerB tool didn’t show any variation in the frequency measurements. It might be because the LabTool has more precision. I went up to 100MHz sample rate and I had the same frequency measurements in each signal. Maybe the AnalyzerB is using some other method to implement an average or it might be over sampling to improve the measurement. I might need to have a third logic analyzer to see what tool is getting a right measurement.   I had some trouble using the LabTool GUI.  For example, I didn't know that LabTool is connected at first since the "LabTool Device" indication was not highlighted.  Also it was difficult to know how to choose the protocol analyzer, so that Combo Box could be improved.  It is clear that the LabTool has more resolution when using the lowest channels. The AnalyzerB tool has only a maximum of 25MSMP for all combinations. So the LabTool has an advantage because it could be 100MHz sample rate in 2 digital channels.   I like the LabTool but it might be a good idea to include test clips for each of the signals because not all the time the target circuit will have pins to plug the actual test points. These test clips will give more functionally to the LabTool.  Also, I would like to have more information about the actual LabTool system if it will be like a reference design for customer, like the source code for the LabTool software and also the firmware for the MCU.   The LabTool could be used for debugging without any issue; I think that the Start Guide should be updated with more detail information to improve the usability.

Description The brushless DC (BLDC) motor control design example describes how to connect and control up to four brushless DC motors using a single NXP microcontroller from the ARM968-based LPC2900 series, making this a low cost solution. Four dedicated motor control PWM blocks keep the CPU load low while running four motors. This allows the microcontroller to still perform other tasks in Hardware used Hitex LPC2939 or LPC2929 evaluation board Hitex BLDC motor control extension board (4x) Interface board Maxon EC32 80W brushless servo motor with Quadrature Encoder Interface (QEI) Three of the Hitex BLDC motor boards are driven as-is (spinning their on-board motors). The fourth board is driving the Maxon EC32 motor using the quadrature encoder interface. The interface board is used to create the correct pin-out that makes it possible to connect the four motor control extension boards to the LPC29xx evaluation board. Block Diagram Documentation BLDC Motor Control Products Below are recommended microcontrollers for use in BLDC motor control applications. Comparison Table Product Pins On-Chip Flash On-Chip RAM Comments LPC2939 208 768KB 56KB Base microcontroller used in the design example. LPC2930 208 0KB 56KB A lower-cost microcontroller with the same amount of pins but without on-chip flash memory. LPC2929 144 768KB 56KB Same on-chip memory as on the LPC2939 but in a smaller package and without USB Host functionality. LPC2927 144 512KB 56KB Same as LPC2929 but with less on-chip flash memory. More Information Image BLDC Motor Control Demo at ESC SV 2009 Schematics LPC2939 Evaluation Board BLDC Motor Control Extension Board Interface Board Example Code BLDC Motor Control Bill of Materials BLDC Motor Controlhttp://www.lpcware.com/sites/default/files/bom.xls Disclaimer This design example shows possible hardware and software techniques used to implement the design. It is imperative that the viewer use sound engineering judgment in determining the fitness of this design example for any particular application. This design example may include information from 3rd parties and/or information which may require further licensing or otherwise. Additional hardware or software design may be required. NXP Semiconductors does not support or warrant this information for any purpose other than an informational design example. lpc2939.eval_.board_.schematics.pdf 143.6 KB documentation.pdf 243.48 KB bldc.board_.schematics.pdf 188.85 KB interface.board_.zip 2 MB example.code_.zip 72.55 KB bom.xls 3.87 KB

Description The Telephone Answering Machine Design Example is a sophisticated telephone answering machine that provides everything commercial devices offer and more. Noteworthy features include improved voice quality and increased storage capacity over commercial machines. Additionally, Internet connectivity enables convenient messaging in the form of SMS messages or e-mails from anywhere in the world. Virtual answering machines can be set up for four different users. A user-friendly interface makes learning how to use this device and taking advantage of its many special features easy for anyone, regardless of their electronics savvy. The highly efficient system is designed around an LPC2138 microcontroller, which features an ARM7 RISC processor. Built with a small handful of components, the Telephone Answering Machine Design Example is cost-effective. The thoughtful inclusion of an external flash memory card and well-chosen algorithms for nearly unlimited storage capacity of crystal-clear messages contribute to the success of the design. Block Diagram Documentation Telephone Answering Machine Products Below are recommended microcontrollers for use in implementing a telephone answering machine. Comparison Table Product Pins On-Chip Flash On-Chip RAM Comments LPC2138 64 512KB 32KB Base microcontroller used in the design example. LPC2136 64 256KB 32KB A lower-cost microcontroller with the same amount of on-chip RAM but with only half the on-chip flash memory. LPC2146 64 256KB 32KB + 8KB An upgraded microcontroller with a USB interface. USB could be used instead of Ethernet to connect to a PC if Internet functionality is not desired. More Information Images Working Prototype Circuit Blocks Answer Flow Telephone Answering Machine Schematics Example Code Bill of Materials Disclaimer This design example shows possible hardware and software techniques used to implement the design. It is imperative that the viewer use sound engineering judgment in determining the fitness of this design example for any particular application. This design example may include information from 3rd parties and/or information which may require further licensing or otherwise. Additional hardware or software design may be required. NXP Semiconductors does not support or warrant this information for any purpose other than an informational design example. documentation.pdf 927.44 KB schematics.pdf 92.13 KB example.code_.zip 646.98 KB bom.txt 1.39 KB

Welcome to the LPC4350 Hitex Board Getting Started Guide! This page will walk new owners of the LPC4350 development platform from Hitex through bringing the board up with the example projects. Connecting the Hardware Here is a photo of a typical hardware setup. The board is connected to a PC through a JTAG debugging interface and a USB-serial cable. +5V center-positive power is also applied to X14. If a 5V regulated power supply is not available, the board may be powered by USB connected to one of the USB connectors using the included cable. To date we have tested this board with a Keil ULink 2, ULink Pro, and the Segger JLink but any JTAG-capable tool should be able to debug with the LPC4350. The example projects should run without modification on Keil MDK. To see the debugging output from the example code on the serial-to-usb cable, first the driver must be installed. Many cables use chips from FDTI and the drivers can be downloaded from here: FDTI VCP Drivers. To view the serial output, any standard terminal program such as Tera Term can be used. LPC4300 Hitex Board with Connections LPC4350 PDL Examples and Flash Drivers The example code for this board can be downloaded from here: LPC4350 PDL There are 53 code examples. Once the code has been downloaded, it should be unzipped. The unzipped peripheral driver library includes an Examples directory containing examples that work with each peripheral on the LPC4350 dual-core microcontroller. Also included are flash drivers located in the Tools\Flash\Keil_Binaries directory. If using ARM/Keil MDK V4.22 and earlier, these should be copied to the C:\Keil\ARM\Flash directory. Later tool versions should include these drivers. LPC4350 PDL Examples and Flash Drivers If you are using the Hitex LPC4350 board using the ARM/Keil MDK, the driver library projects have several configurations built-in. They can build for Internal SRAM, build for SPIFI (external 1 MB QSPI flash on the Hitex board), or build for Hitex Flash (external parallel flash on the Hitex board).The best performance will be achieved with building for Internal SRAM, but if you would like the board to boot on its own without a debugger, then the code will have to be built either for SPIFI or for Hitex Flash. LPC4350 PDL Keil Project Configurations LPC4350 PDL Boot Jumpers Once you have successfully programmed the flash on the Hitex board, there is one step left before the LPC4350 can boot from external flash. That final step is to configure the boot mode using the boot mode jumpers. LPC4350 PDL Boot Jumpers Here is a diagram that shows how to configure the boot jumpers on the LPC4350 Hitex board. The boards are shipped with the center two positions shorted with jumpers. This configures the LPC4350 to boot from the "EMC" (External Memory Controller) which is connected to the parallel flash on the Hitex board. When using the sample projects with the Keil tool, after building a project, the LOAD button can be used to program it into Flash memory for stand-alone booting. To debug a project that has been programed in to Flash, you may need to click the LOAD button to configure the memory controller on the LPC4350 (if it has been reset) before entering debug mode. LPC4350 PDL Boot Jumper Diagram We can ship boards with two example projects flashed in them- one loads when the board is configured to boot from Parallel Flash, and a second loads when the board is configured to boot from QSPI flash. Recent boards are shipped with a Mass Storage Class ROM USB demo in parallel Flash and an LED/button demo in QSPI Flash. Using the SD/MMC Card Slot The SD/MMC Card Slot, on the right edge of the board in the photo above, can accept an SD card to read and write data. Before this slot will work properly, several jumpers must be configured on the Hitex board. The jumpers needed are: Jumper Block Jumper Settings SV3 positions 7-8 and 13-4 must be open SV6 positions 1-2, 3-4, 7-8, 15-16, 17-18 must be open SV12 all positions must be shorted JP9 position 1-2 must be shorted Next- load the Usb_MassStorage example from the USBDEV_ROM directory. This Mass Storage Class example has been extended with sdio drivers. Insert an SD card (we have tested 2GB) into the SD connector on the right side of the board. Connect X2 (USB1, high-speed) to a PC. You should see a disk drive on the PC and be able to read and write the SD card. Operation at 204 MHz The LPC4350 is qualified to operate at up to 204 MHz, but normally starts up at a slower speed to make design easier. In particular, even if memories and power subsystems are not designed to support 204 MHz, booting is still possible. To run the LPC4350 at 204 MHz, take a look at the BOOTFAST example project. This project supports the same configurations (SRAM, Parallel Flash, and QSPI Flash) as the other examples, but after startup, it relocates some code to internal SRAM, and then it reconfigures the parallel flash and SPIFI peripheral to a high speed mode and increases the clock speed to 204 MHz. This is a good way to see how a standard system would boot. Typically, the most critical code would also be located within internal SRAM which runs at 204 MHz with zero wait states while other less performance-intensive code could be located in external Flash, SRAM, or QSPI flash which are set up to run at 102 MHz in this example. Multi-Core Operation The LPC4350 contains two cores, a Cortex-M4 and a Cortex-M0 which both operate at 204 MHz. An example that demonstrates how you can use the cores together is located in Examples\DUALCORE\Mbx_Demo. This example sets up a mailbox mechanism to facilitate communication between the two cores. The M0 core is assigned the task of outputting serial communications via UART 1. This example includes a multi-project workspace. Once the workspace is opened, the M0 project must be built first before the M4 project can be built. For more details, see the abstract in the M4 project. State Configurable Timer (SCT) The LPC4350 contains a special timer called the State Configurable Timer (SCT). The SCT is a timer with a state machine integrated into it. It is great for doing complex signal generation such as PWM waveforms. An SCT example is provided in the LPC4350 code repository which emulates the behavior of a simple traffic light. The example is called SCT_TrafficLight and is in the SCT subdirectory of the Examples directory in the code bundle. To use this example, you must assemble a PCB with four LEDs and two pushbuttons. Here is a photo of an example board: SCT Traffic Light SCT Traffic Light Schematic The traffic light should be connected as follows: Signal Port Connector Signal Wire Color CTOUT_0 P4_2 X11, pin 7 Red LED red CTOUT_1 P4_1 JP20, pin 2 Yellow LED yellow CTOUT_2 P4_4 JP22, pin 2 Green LED green CTOUT_3 P4_3 X11, pin 6 White LED red CTIN_2 P4_10 X11, pin 13 WALK Button blue CTIN_3 P7_3 SV18, pin 16 RESET button yellow GND ADC ADC, GND Common black Traffic Light Connections If you would like to edit the state machine used in the traffic light example, you will need to use the LPCXpresso or Red Suite tool, which has "Red State," a state-machine editor, built-in. Here is an image of the state machine used in the traffic light example: Traffic Light Diagram Once you have edited the state machine, click "Generate Code." You can test the state machine within LPCXpresso if you have a Red Probe or an LPC-Link probe, or you can copy the following source code files from the LPCXpresso project over to the Keil SCT project: sct_fsm.c, sct_fsm.h, and sct_user.h and make use of a JLink or uLink. Serial GPIO (SGPIO) The LPC4350 contains a peripheral called Serial GPIO which is similar to a bank of shift registers with some extra logic for bonding and counters for timing. The SGPIO is great for implementing standard or custom digital data interfaces. To demo this peripheral, we have configured it to implement four I2S ports to add 7.1 8-speaker audio capability to the LPC4300 family. The example for this will soon be provided in the LPC4350 code repository. The example will be called SGPIO_71 and will be in the SGPIO subdirectory of the Examples directory in the code bundle. To use this example, you need a demonstration PCB with four stereo audio codecs on board. Here is a photo of an example board: LPC4350 Codec Board The codec board should be connected as follows: Signal Connector Wire Color MCLK SV16, pin 6 blue LRCLK SV3, pin 11 green SCLK SV5, pin 6 yellow GND GND post near U23 black V33 JP5, pin 2 red - - - SDIN0 SV13, pin 4 blue SDIN1 SV5, pin 4 green SDIN2 SV16, pin 4 yellow SDIN3 SV3, pin 3 blue LPC4300 Hitex Codec Connections Once you have connected the codec board, you should be able to connect the Hitex board to your PC using a USB cable to connector X2. After running the example project, a stereo USB speaker device should appear on your PC which can accept audio and mirror it onto two of the stereo audio channels.

View Webinar Recording