LPC Microcontrollers Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

LPC Microcontrollers Knowledge Base

Discussions

Sort by:
Getting Started with LPCXpresso54608  & MCUXpresso is pretty straight forward, but we want to make the process even easier.  So we created a  simple guide to walk you through the getting started process,         LPCXpresso54608: Out of Box & Getting Started Introduction LPC5460x MCU Family part numbering & feature summary table (highlighted in yellow are the first of many parts to be released). If it wasn't already clear, LPCXpresso54608 is the superset development board for our LPC5460x MCU Family. NXP.com Board Page Board Part Number (OM13092) Board User Manual (UM11035) Board Schematics Key features of the LPCXpresso54608 development board, 272x480 color LCD with capacitive touch screen On-board, high-speed USB, Link2 debug probe with CMSIS-DAP and SEGGER J-Link protocol options UART and SPI port bridging from LPC546xx target to USB via the on-board debug probe Support for external debug probe 3 x user LEDs, plus Reset, ISP (3) and user buttons Multiple Expansion options, including Arduino UNO and PMod Built-in power consumption measurement for target LPC546xx MCU 128Mb Micron MT25QL128 Quad-SPI flash 8MB Micron MT48LC8M16A2B4 SDRAM Knowles SPH0641LM4H digital microphone Full size SD/MMC card slot NXP MMA8652FCR1 accelerometer Stereo audio codec with line in/out High and full speed USB ports with micro A/B connector for host or device functionality 10/100Mbps Ethernet (RJ45 connector)
View full article
First, download the LPCXpresso54608 board User Manual.  After scanning the document, let's get started! Plug in LPCXpresso54608 (as shown below).  You will see the pre-loaded, Out of Box demo, which features Draupner TouchGFX.  A screen shot is shown below, Once you've explored the pre-loaded demo, you will likely want to learn more.   For this you will need to configure and build an  MCUXpresso Software Development Kit (SDK)  for your LPCXpresso54608 development board. Register or use your login credentials to sign in and download software from NXP. You can create a configuration for the LPCXpresso54608 in one of two ways: By typing 'LPCXpresso54608' or selecting boards>LPC>LPCXpresso54608 Once you have selected the board you will be presented with two options: 'Select Configuration' or 'Specify Additional Configuration Settings'. (It is recommended that you name the configuration something that specifies the settings as this will help identify multiple configurations.)   Note: By default the SDK Builder will choose IAR as the default toolchain for Windows.  For this tutorial we will use Windows as our Development Host OS.  If this is not the desired toolchain or OS please 'Select 'Specify Additional Configuration Settings' The following window will be presented, which allows you to download an SDK for IAR, Keil or Both (selecting 'All toolchains'.).  During this stage, you can also specify any necessary middleware for your download.  You can select or deselect these under the 'Select Optional Middleware' Select 'Go to SDK builder' once you have made your choices. Note:You may be prompted to update your info before you are allowed to download the package. If this happens select the link in the red at the top to resolve any issues. Once the information is updated you can click on the 'Overview' at the top and reselect 'SDK Builder' to return to the screen you were on. You have the opportunity to rename your file one last time before you hit download now. Once you select 'Download Now' you will be presented with a license agreement and once agreed to the download will start. Once you have downloaded the packaged .zip use your favorite utility to extract to a known location --> Continue here if IAR is your selected default toolchain. --> Continue here if KEIL is your selected default toolchain. --> Continue here if MCUXpresso is your selected default toolchain (coming March 2017!)
View full article
Hello community!   Attached is a document that explains how to build and run the LPCOpen Ethernet example projects, it also explains the needed board and PC connections and configurations. The steps described in the document were done using the LPC1769 MCU like the one in the LPCXpresso board for LPC1769 with CMSIS DAP probe, but the same principles are applicable to any LPC MCU. The steps described in this document are valid for the following versions of the software tools: o    LPCXpresso v8.1.4 o    LPCOpen v2.xx Boards o    LPCXpresso board for LPC1769 with CMSIS DAP probe o    EA LPCXpresso BaseBoard o    LPC-Link2 Contents 1. Overview and concepts    1.1    LPCOpen       1.1.1 Core driver library       1.1.2 Middleware       1.1.3 Examples       1.1.4 LPCOpen with an RTOS 2. Running the lwip_tcpecho and webserver demo applications    2.1 Downloading a LPCOpen package    2.3 Setting up the hardware       2.3.1 LPCXpresso board for LPC1769 with CMSIS DAP probe       2.3.2 EA LPCXpresso BaseBoard    2.2 Importing the LPCOpen examples    2.4 Building the demo applications    2.5 Running the demo applications       2.5.1 lwip_tcpecho_sa demo       2.5.2 webserver demo Appendix A - References I hope you can benefit from this post, if you have questions please let me know.   Best Regards! Carlos Mendoza
View full article
This document explains how to create a new project using MCUXpresso IDE for a LPCXpresso1549 board. There is important to mention that there is no SDK for LPC15xx device family so we are using LPCOpen libraries.   MCUXpresso IDE introduction   MCUXpresso IDE is based on the Eclipse IDE and includes the industry standard ARM GNU toolchain. It brings developers an easy-to-use and unlimited code size development environment for NXP MCUs based on Cortex-M cores (LPC and Kinetis). MCUXpresso IDE debug connections support Freedom, Tower®, LPCXpresso and your custom development boards with industry- leading open-source and commercial debug probes including LPC-Link2, P&E and SEGGER. The fully featured debugger supports both SWD and JTAG debugging, and features direct download to on-chip flash. When MCUXpresso IDE is installed, it will contain pre-installed part support for most LPC based MCUs. Example code for these pre-installed parts is provided by sophisticated LPCOpen packages (and Code Bundles). Each of these contains code libraries to support the MCU features, LPCXpresso boards (and some other popular ones), plus a large number of code examples and drivers.   In addition, MCUXpresso IDE’s part support can be extended using freely available MCUXpresso SDK2.x packages. These can be installed via a simple ‘drag and drop’ and automatically extend the IDE with new part knowledge and examples. SDKs for MCUXpresso IDE can be generated and downloaded as required using the SDK Builder on the MCUXpresso Config Tools website at: http://mcuxpresso.nxp.com/   Create a new project   For this document, we are using the LPCXpresso1549 board (for this MCU an LPCOpen project exists), however the process is the same for any LPCXpresso board. It is necessary to download the LPCOpen bundle for your target MCU/board and import it into your Workspace, LPCOpen is available in the next link:  http://www.nxp.com/lpcopen Select “New project” in the QuickStart panel, this will open a new window   Select the desire board. For this case, we are using the LPCXpresso1549, and click “Next” NOTE: When the board is selected, you can see highlighted in the above figure that the matching MCU (part) is selected automatically. If no matching board is available, the required MCU can be selected from the list of Pre-Installed MCUs. The MCUXpresso IDE includes many project templates to allow the rapid creation of correctly configured projects for specific MCUs. This New Project wizard supports 2 types of projects: Those targeting LPCOpen libraries Standalone projects In this case, we will show the steps in creating a LPCOpen- Cproject. This option creates a simple C project, with the main() routine consisting of an infinite while(1) loop that increments a counter. In additions, code will also be included to initialize the board and enable a LED. Select the project name and click “Next” When creating an LPCOpen-based project, the first option page that you will see is the LPCOpen library selection page. It is necessary import the LPCOpen Chip Library for the device used and optionally the LPCOpen Board Library Project, the below window allows to import the libraries if you have not already done so. Follow the below steps: a. Click on “Import…”, a new window will appear, select the archive file to import. In this case, the projects imported are contained within archives .zip. For this example, the LPCXpresso1549 board is selected. Click “Open”. Then click “Next” b. Select only the LPCOpen Chip Library and LPCOpen Board Library Project. Click “Finish” Select LPCOpen Libraries. Click “Next” Select CMSIS Library project. The CMSIS library option within the MCUXpresso IDE allows you to select which (if any) CMSISCORE library you want to link to from the project you are creating. For this case we selected “None” as default. Click “Next” NOTE: The use of LPCOpen instead of CMSIS-CORE library projects is recommended in most cases for new projects. Enable SWO trace clock. Click “Next” Enable linker support for CRP. Click “Next” The “Semihosting C Project” wizard for some parts provides two options for configuring the implementation of printf family functions that will get pulled in from the Redlib C library: Use non-floating-point version of printf If your application does not pass floating point numbers to printf() family functions, you can select a non-floating-point variant of printf. This will help to reduce the code size of your application. For MCUs where the wizard does not provide this option, you can cause the same effect by adding the symbol CR_INTEGER_PRINTF to the project properties. Use character- rather than string-based printf By default printf() and puts() make use of malloc() to provide a temporary buffer on the heap in order to generate the string to be displayed. Enable this option to switch to using “character-by-character” versions of these functions (which do not require additional heap space). This can be useful, for example, if you are retargeting printf() to write out over a UART – since in this case it is pointless creating a temporary buffer to store the whole string, only to print it out over the UART one character at a time. For MCUs where the wizard does not provide this option, you can cause the same effect by adding the symbol CR_PRINTF_CHAR to the project properties. For this example we will maintain as default. Having selected the appropriate options, you can then click on the Finish button, and the wizard will create your project for you, together with appropriate startup code and a simple main.c file. At this point you should be able to build and debug this project Writing my first project The LPCOpen Chip Library (in this case lpc_chip_15xx) contains the drivers for some LPC peripherals. For these examples, we will use the GPIO Driver. The LPCOpen Board Library Project (in this case lpc_board_nxp_lpcxpresso_1549) contains files with software API functions that provide some simple abstracted functions used across multiple LPCOpen board examples. The board_api.h contains common board definitions that are shared across boards and devices. All of these functions do not need to be implemented for a specific board, but if they are implemented, they should use this API standard. After create a new project using MCUXpresso and LPCOpen, it is created a simple C project where it is initialized the board and set the LED to the state of "On" using the Board_LED_Set function. In this example, we will toggle the a LED using a push bottom. In LPCXpresso1549 board le LEDs are connected to PIO1.1, PIO0.3 and PIO0.25 pins. And the SW1 to PIO0.17 pin. The function Chip_GPIO_SetPinDIRInput configures a pin as input.  The function Chip _GPIO_GetPinState gets a GPIO pin state via the GPIO byte register. The function Board_LED_Set set the LED to the state of "On" or “Off”.. Complete code (Set the LED using a push bottom).   /* ===============================================================================  Name        : LPCXpresso_new_example.c  Author      : $(author)  Version     :  Copyright   : $(copyright)  Description : main definition ===============================================================================  */   #if defined (__USE_LPCOPEN) #if defined(NO_BOARD_LIB) #include "chip.h" #else #include "board.h" #endif #endif   #include <cr_section_macros.h>     int main( void ) {         bool State_Input;   #if defined (__USE_LPCOPEN)        // Read clock settings and update SystemCoreClock variable        SystemCoreClockUpdate();   #if !defined(NO_BOARD_LIB)        // Set up and initialize all required blocks and        // functions related to the board hardware        Board_Init();        Chip_GPIO_SetPinDIRInput(LPC_GPIO, 0, 17); //Set GPIO direction for a single GPIO pin to an input   #endif #endif          while (1) {                State_Input=  Chip_GPIO_GetPinState (LPC_GPIO, 0, 17);  //Get a GPIO pin state via the GPIO byte register                if (State_Input==0){                       Board_LED_Set (0, true); // Set the LED to the state of "On"                }                else   {                       Board_LED_Set (0, false); // Set the LED to the state of "Off"                }        }        return 0 ; }  
View full article
This cook book includes lots of interesting examples leveraging LPC MCU's powerful SCT Timer. Have fun using them, creating more and sharing more. #sct‌
View full article
Unboxing video of the low cost OKDO E1 board.    As a quick demo, I hooked up the E1 to a low cost  240x240 Pixel IPS display from buydisplay.com.
View full article
Hello community!   Attached is a document that explains the steps to use LPCXpresso with the LPCOpen projects for your preferred device and platform. The steps described in the document were done using the LPC54102 MCU like the one in the LPCXpresso Board for the LPC54100 family of MCUs, but the same principles are applicable to any LPC MCU. The steps described in this document are valid for the following versions of the software tools: o    LPCXpresso v8.1.4 o    LPCOpen v3.xx Contents 1. Overview and concepts    1.1    LPCOpen       1.1.1 Core driver library       1.1.2 Middleware       1.1.3 Examples       1.1.4 Using LPCOpen with an RTOS 2. Running the demo applications    2.1 Downloading a LPCOpen package    2.2 Importing the LPCOpen examples    2.3 Building and debugging blinky project Appendix A - References I hope you can benefit from this post, if you have questions please let me know.   Best Regards! Carlos Mendoza
View full article
Recently I have several customers experience HardFault error when perform AHB FLASH memory read on LPC55S69. If a FLASH sector has never been programed after mass erase, performing AHB reads of the FLASH memory contents will cause a hardware fault if an unrecoverable error is detected. Why? LPC55Sxx parts are delivered from the factory mass erased with ECC unset. When MCUXpresso IDE connects a chip via LinkServer, it will firstly erase the sectors that will be used for the image being programed, then program the code with a correct ECC set. The sectors beyond the end of the image will be left unchanged, which keep in “erased” states without ECC set on them.   When LPC55Sxx executes FLASH read code ( for example, mytemp = *( uint32_t *)0x4000 ) through AHB bus, it checks FLASH ECC while AHB read. No issue to read programed sectors because ECC has already set. But, read unprogrammed sectors with invalid ECC values leads to fail to read and go to HardFault_Handler as below: If performing AHB reads of the flash memory contents AFTER a sector erase, we will have the same HardFault issue. Solutions There are two solutions to fix the error. 1. Read FLASH Content after Programing the FLASH Sector Unlike mass erasing, programing FLASH updates the related ECC value. Thus with a successful ECC check, read AHB can be realizable by below code. volatile uint32_t mytemp ; …… mytemp = * ( uint32_t * ) 0x1000 ; //read memory content 0x1000 to mytemp‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ NOTE: 0x1000 MUST be a “programed” address. If the unused FLASH sector is in “erased” state, in order to read it, we need manually program it before AHB read. FLASH programming demo code can be referred in flashiap demo under MCUXpresso SDK package. See function FLASH_Program. 2. Read FLASH Content Using FLASH Controller Command Read operations using FLASH controller commands (See UM11126 Section “Command listing (CMD)” ) will not cause hard fault. This is the UM recommended method of read FLASH content. Note: Flash operations (erase, blank check, program) and reading a single word can only be performed for CPU frequencies of up to 100 MHz. These operations cannot be performed for frequencies above 100 MHz. So far I haven’t found a FLASH read demo code. Please follow below steps to create your demos. Environment: IDE: MCUXpresso IDE v11.1.0 SDK MCUXpresso SDK v2.7.0 Steps: See attached document. Thanks for the suggestion from  Alex Yang  and andybeeson‌
View full article
This document describes how to create a new LPC project using LPCOpen v2.xx, LPCXpresso v8.2.2 and LPC11U24 LPCXpresso board. In addition describes how to create 2 simple example codes. Blinking LED. Set the LED using a push bottom.  LPCOpen LPCOpen is an extensive collection of free software libraries (drivers and middleware) and example programs that enable developers to create multifunctional products based on LPC microcontrollers. After install LPCXpresso, the LPCOpen packages for supported board(s)/device(s) can be found at the path: <install_path>\lpcxpresso\Examples\LPCOpen > This directory contains a number of LPCOpen software bundles for use with the LPCXpresso IDE and a variety of development boards. Note that LPCOpen bundles are periodically updated, and additional bundles are released. Thus we would always recommend checking the LPCOpen pages to ensure that you are using the latest versions. This example was created using the LPC11U24 LPCXpresso board in this case the drivers selected is lpcopen_v2_00a_lpcxpresso_nxp_lpcxpresso_11u14.zip Importing libraries In order to create a new project, it is necessary to first import the LPCOpen Chip Library for the device used and optionally the LPCOpen Board Library Project. For do that it is necessary to follow these steps: 1. Click on Import project(s). 2. Select the examples archive file to import. In this case, the projects imported are contained within archives .zip.  3. For this example the LPC11U14 LPCXpresso board is selected. Click Open. Then click Next 4. Select only the LPCOpen Chip Library and LPCOpen Board Library Project. Click Finish. The same steps are required for any LPC device and board you are used. Creating a new LPC project.   The steps to create a new LPC project are described below: 1. In Quickstar Panel, click "New project"   2. Choose a wizard for your MCU. In this case LPC1100/LPC1200 -> LPC11Uxx -> LPCOpen-C Project This option will link the C project to LPCOpen. Then click Next.   3. Select the Project name and click Next.   4. Select the device used (LPC11U24 for this case) and click Next.   5. Select the LPCOpen Chip Library and LPCOpen Board Library, these projects must be present in the workspace.   6. You can set the following option as default clicking Next, then click Finish.   7. At this point, a new project was created. This project has a src (source) folder, the src folder contains: cr_startup_lpc11uxx.c: This is the LPC11Uxx Microcontroller Startup code for use with LPCXpresso IDE. crp.c: Source file to create CRP word expected by LPCXpresso IDE linker. sysinit.c: Common SystemInit function for LPC11xx chips. <name of project> my_first_example: This file contains the main code.     8. LPCXpresso creates a simple C project where it is reading the clock settings and update the system core clock variable, initialized the board and set the LED to the state of "On". 9. At this point you should be able to build and debug this project.   Writing my first project using LPCXpresso, LPCOpen and LPC11U24.   This section describes how to create 2 simple example codes. Blinking LED. Set the LED using a push bottom. The LPCOpen Chip Library (in this case lpc_chip_11uxx_lib) contains the drivers for some LPC peripherals. For these examples, we will use the GPIO Driver. The LPCOpen Board Library Project (in this case nxp_lpcxpresso_11u14_board_lib) contains files with software API functions that provide some simple abstracted functions used across multiple LPCOpen board examples. The board_api.h contains common board definitions that are shared across boards and devices. All of these functions do not need to be implemented for a specific board, but if they are implemented, they should use this API standard.   After create a new project using LPCXpresso and LPCOpen, it is created a simple C project where it is initialized the board and set the LED to the state of "On" using the Board_LED_Set function.   int main( void ) {   #if defined (__USE_LPCOPEN)     // Read clock settings and update SystemCoreClock variable     SystemCoreClockUpdate(); #if !defined(NO_BOARD_LIB)     // Set up and initialize all required blocks and     // functions related to the board hardware     Board_Init();     // Set the LED to the state of "On"     Board_LED_Set(0, true); #endif #endif       // TODO : insert code here       // Force the counter to be placed into memory     volatile static int i = 0 ;     // Enter an infinite loop, just incrementing a counter     while (1) {         i++ ;     }     return 0 ; }       a. Blinking LED. In board_api.h file there is an API function that toggle the LED void Board_LED_Toggle( uint8_t LEDNumber);   LEDNumber parameter is the LED number to change the state. The number of the LED for the LPCXpresso LPC11U24 is 0. It is easy to create a delay function using FOR loops. For example: void Delay ( unsigned int ms) {         volatile static int x,y;           while (ms)         {                 for (x=0; x<=140; x++)                 {                         y++;                 }                 ms--;         } } In order to have the LED blinking, it is necessary to call these functions in an infinite loop. while (1) {                 Board_LED_Toggle(0);                 Delay (10000);         } Complete code (Blinking LED). int main( void ) { #if defined (__USE_LPCOPEN)         // Read clock settings and update SystemCoreClock variable         SystemCoreClockUpdate(); #if !defined(NO_BOARD_LIB)         // Set up and initialize all required blocks and         // functions related to the board hardware         Board_Init();         // Set the LED to the state of "On"         Board_LED_Set(0, true); #endif #endif          while (1) {                 Board_LED_Toggle(0);                 Delay (10000);         }         return 0 ; }  void Delay ( unsigned int ms) {          volatile static int x,y;         while (ms)         {                 for (x=0; x<=140; x++)                 {                         y++;                 }                 ms--;         } }      b. Set the LED using a push bottom. For this example it is necessary to configure a pin as input.  The gpio_11xx_1.h file contains all the function definitions for the GPIO Driver. The example uses the pin 16 of port 0 to connect the push bottom. The function Chip_GPIO_SetPinDIRInput ( LPC_GPIO_T *pGPIO, uint8_t port, uint8_t pin) sets the GPIO direction for a single GPIO pin to an input. In order to configure the Port 0, pin 16 as input we can use this function: Chip_GPIO_SetPinDIRInput(LPC_GPIO, 0, 16); Then, it is necessary to check the status of this pin to turn-on/turn-off the LED. The function Chip_GPIO_GetPinState ( LPC_GPIO_T *pGPIO, uint8_t port, uint8_t pin) gets a GPIO pin state via the GPIO byte register. This function returns true if the GPIO is high, false if low. State_Input=  Chip_GPIO_GetPinState (LPC_GPIO, 0, 16);   Complete code (Set the LED using a push bottom). int main( void ) {         bool State_Input;   #if defined (__USE_LPCOPEN)     // Read clock settings and update SystemCoreClock variable     SystemCoreClockUpdate(); #if !defined(NO_BOARD_LIB)     // Set up and initialize all required blocks and     // functions related to the board hardware     Board_Init();     Chip_GPIO_SetPinDIRInput(LPC_GPIO, 0, 16);     // Set the LED to the state of "On"     Board_LED_Set(0, false);  #endif  #endif      while (1) {           State_Input=  Chip_GPIO_GetPinState (LPC_GPIO, 0, 16);              if (State_Input==0){                 Board_LED_Set(0, true);             }              else {                 Board_LED_Set(0, false);              }     }     return 0 ; }   I hope this helps!! Regards Soledad
View full article
    Writing this post just want to remind the customer of RAM allocation when use the on-chip CAN drivers in LPC11C24. Otherwise, when meet the abnormal issues, it is difficult to locate the root reason and it also causes a waste of time.      Now, take a real customer question as an example, to highlight the RAM allocation importance when using the on-chip CAN API in LPC11C24. Problem description     Customer used the LPC11C24 on-chip CAN API to realize the CAN frames sending and receiving, the CAN code was from the official lpcopen, and it worked OK when he just used the CAN code. But when customer added the UART code, they found the code always enter hardfault after a short time running. They test the UART code which without the CAN code directly, the UART code worked perfectly. It means, independent UART code and independent CAN code are all working normally, but when combine the UART and on-chip CAN code together, the code will enter hardfault. Problem analysis From the Cortex M0 devices generic user guide, we can get the information about the hard fault:     Faults are a subset of exceptions, see Exception model . All faults result in the HardFault exception being taken or cause lockup if they occur in the NMI or HardFault handler. The faults are:      execution of an SVC instruction at a priority equal or higher than SVCall      execution of a BKPT instruction without a debugger attached      a system-generated bus error on a load or store      execution of an instruction from an XN memory address      execution of an instruction from a location for which the system generates a bus fault      a system-generated bus error on a vector fetch      execution of an Undefined instruction      execution of an instruction when not in Thumb-State as a result of the T-bit being previously cleared to 0      an attempted load or store to an unaligned address Now we debug the problem project to check, which detail code line caused this hardfault problem. When the code enters the hardfault handler, check the MSP address in the flash, then find the LR register, which will link to the code before entering in the hardfault handler, the following are the according debug result:   The LR register is 0X1FFF2C1F, it means before enter in hardfault handler, the code runs to this address code. Now, check the 0X1FFF2C1F in the memory map.    We can find the address is in the ROM area, because we just use the ROM CAN driver, UART is just the pure register control code, then we can get the problem still relate to the on-chip CAN driver, not the UART code. But we can’t see or debug the detail ROM CAN driver directly, we still can’t find the root problem.    Even we know the problem is not caused by the UART, but another important clue which relates to the UART function also influence the test result after I do a lot of testing. In the customer code, he defines the UART user transmit and receive buffer like this: #define UART_SRB_SIZE 128    // Send #define UART_RRB_SIZE 32    // Receive /* Transmit and receive buffers */ static uint8_t rxbuff[UART_RRB_SIZE], txbuff[UART_SRB_SIZE];   On one occasion, I tried changing #define UART_SRB_SIZE 128 To  #define UART_SRB_SIZE 32 Just minimize the txbuff size, I found the code won’t enter in the hardfault handler any more. It seems very strange and contradiction with the hardfault handler enter point which is test before.    I also check the generated code size, the used RAM and flash size is:   text       data        bss        dec        hex    filename    7672          0        244       7916       1eec    pscan.axf LPC11C24 RAM is 8K, here just 244 Bytes, the stack also use the whole RAM, so the 8K RAM size should be enough to use.   In this situation, I check the project’s .map file about the txbuff with 128 and 32 respectively.    1) txbuff with 128Bytes Rxbuff and txbuff occupy the RAM address from 0X10000048 to 0X100000E8.     2) txbuff with 32Bytes Rxbuff and txbuff occupy the RAM address from 0X10000048 to 0X10000088. We can find the txbuff start address is the same, just the end address has difference.    With these information, we checked the LPC11C24 user manual chapter C_CAN on-chip drivers again, we found a significant description:      0X10000050 to 0X100000B8 is used by the on-chip CAN API RAM, and from the issue project, memory map file, we can find rxbuff and txbuff RAM address is 0X10000048 to 0X100000E8, it already occupies the whole CAN API RAM, this is the key point. Minimize the txbuff, then rxbuff and txbuff occupy the RAM address from 0X10000048 to 0X10000088, this address doesn’t occupy the whole on chip CAN API RAM, in this situation, the problem doesn’t happen, I think the used CAN API may in the RAM address 0X10000089-0X100000B8.    Anyway, just minimize the buffer size can’t solve the problem from the root side. We must follow the user manual to keep the RAM address from 0x10000050 to 0x100000b8 won’t be used by any other application code.   Problem solutions      From the above chapter, we can find the root problem is the application code occupies the on-chip CAN RAM, to solve the problem, we need to modify the linker file, to prevent the usage of on-chip CAN RAM range.      Because the customer is using the LPCXPresso IDE, then we take this IDE as an example, to protect the RAM address 0x10000050 to 0x100000b8. From the above, we can get that the LPCX11C24 have 8Kbytes RAM, normally, customer will define it just in one, now we divide the RAM to two pieces. 1) RAM2: Location 0X10000000, size 0X100 2) RAM: Location 0X10000100, size 0X1F00 In the LPCXpresso, Project Properties -> C/C++ Build -> MCU settings, then modify it like this:     Then generate the code, and check the map file again.   RAM address from 0x10000000 to 0X10000FF is not used by any other application code. All the application code RAM is using from address 0x10000100. After long time testing, we find the hardfault problem never happens, on customer side, it also works OK. In conclusion, when customer want to use the on-chip CAN API, they need to protect the RAM address from 0x10000050 to 0x100000b8 in the linker file.    
View full article
The DMX512 master and slave board (OM13043) are no longer available. This page is provided for reference purposes only. Board information and code is available in the zip file attached to this posting. NXP offers dedicated components to realize DMX512 based systems for both communication and power stages. The reference design provides a basic set of commands (including Remote Device Management) that can be used as a starting point to develop next-generation DMX512 platforms. The DMX512 Software Development Kit (SDK) for the LPC11xx/LPC11Uxx installer contains: AN11153 - Describes the use of the NXP LPC111x Cortex M0 microcontroller to create an RDM enabled DMX512 Slave AN11154 – Describes the use of the NXP LPC11U1x Cortex M0 microcontroller to create a RDM enabled DMX512 Master (USB - DMX interface) UM10536 - Explains how to get started with the NXP DMX512 Master (USB - DMX interface) and DMX512 Slave (demo board for DMX fixture) and the NXP Windows .NET DMX512control application Software Package – DMX master and slave implementation for LPCXpresso toolchain and Windows .NET GUI Schematics, Gerber files and BOM List The SDK is attached to this page (see below) for REFERENCE PURPOSES ONLY. DMX512 Master Board DMX512 Slave Board System notes Controller side: LPC1100XL microcontroller (up to 50 MHz - 45 DMIPS) offers performance needed to integrate DMX message coding/decoding and PWM generation in a single chip Industry-leading low active power consumption of 110 uA/MHz for bus-powered devices Storage of scene settings in non-volatile memory using EEPROM emulation in flash, or integrated EEPROM in LPC11E00 series Up to four 16-bit and 32-bit timers, generating up to 11 PWM signals to control and dim the ballast Reduced development complexity - software can be written in C Reduced bill of materials – significant cost savings through Cortex-M0 architecture, plus many built-in peripherals to interface with lighting drivers and network in LPC1100XL Power stage: LED dimming using the PWM input of the NXP UBA3070 DC-to-DC LED driver with up to 98% efficiency SSL4101 provides mains isolation for both the RGB LED power stage and the DMX wires Low component count and high efficiency through integrated PFC and flyback control functionality GreenChip TEA1721 buck converter supplies LPC1100XL with high efficiency; no-load power consumption levels 10 mW Implementation example (DMX512 slave unit): RDM-enabled DMX512 slave or receiver built around the NXP LPC111x Cortex-M0 microcontroller Features four DMX controllable LEDs, a red heartbeat LED, a green traffic LED, DIP switches for selecting the DMX start address, a 5-position joystick, and an optional LCD The UART and the 16-bit timer/counters of the LPC111x MCU are the main hardware blocks needed The I2C hardware block is used to interface with the (optional) LCD functionality References to DMX512 refer to DMX512-A, since both hardware and software are designed using the latest standard Implementation example (DMX512 master unit): DMX512 controller and monitoring device, built around the NXP LPC11U1x microcontroller, enabling Remote Device Management (RDM) Features a USB interface, a red heartbeat LED, and a green traffic LED The USB and UART of the LPC11U1x MCU are the main hardware blocks needed
View full article
Symptoms Many LPC55 users experienced connection failure when using ISP USB0 for firmware update. In practice, we don’t suggest user updating firmware via ISP USB0 for LPC55(S)6x/ 2x,LPC55(S)1x/0x parts. Diagnosis LPC55 USB0 is Full Speed USB port. The default setting of CMPA turns off the USB0 port. Some users may reconfigure CMPA to enable ISP USB0 in order to use ISP USB0 BOOT, but this is not recommended in practice. LPC55 ISP USB0 uses internal FRO as clock source. According to LPC55 data sheet, the FRO accuracy is only +-2%, while the FS USB data rate tolerance specification is +-2500ppm(+-0.25%). Obviously, the LPC55 FRO spec can’t meet the USB0 clock accuracy requirement. See below extraction from NXP manuals. Fig 1. The accuracy of FRO ( Extracted from LPC55S69 Datasheet )   Fig 2. The accuracy requirement of USB FS( Extracted from TN00063 )   Some users may wonder why USB0 can use internal FRO as clock source in the user application?  Whenever internal clock source FRO is used as USB0 clock source, we must calibrate FRO in source code for communication. That’s to say, trim FRO to an accurate frequency. We can see FRO trim in many MCUXPressoSDK USB demos. When using FRO as the USB0 clock source, in order to ensure the USB0 clock accuracy, we must use the USB0 SOF frame synchronization to calibrate the FRO in order to ensure the accuracy of FS USB clock source (reference design of TN00063, TN00063-LPC5500 Crystal-less USB Solution). Unfortunately, the BOOT ROM of LPC55 does not support USB SOF calibrating FRO. As a result, even if we enable ISP USB0, the FRO clock drift can still cause USB0 communication failure under non-room temperature conditions. Solution Since ISP USB0 is not recommended for firmware update, the user manual no longer announces the enablement bit of ISP USB0 in CMPA. If you need to use USB0 for firmware update, we recommend using ISP USB1 (High Speed USB), because USB1 uses accurate external clock source which can ensure the ISP USB1 working stable. In addition, the communication protocol of ISPUSB complies with BLHOST specification. For details, see:  blhost User's Guide - NXP  
View full article
Previously, I wrote two articles about LPC55xx AHB read ( How to fix AHB Read HardFault Error ) and LPC55xx FLASH alignment ( Why FLASH Program cannot Success?  ). In this article, we will go on investigating LPC55xx erased memory state. For most of NXP MCU, the erased FLASH state is 0xFF. Writing action is to change 1 to 0. However for LPC55, when we perform mass erase or section erase, we see the related memory turns to all 0 in MCUXpresso IDE debugger Memory view. This all-0-erased-status confuses many LPC55 beginners. Is this real memory state? The answer is yes, IDE debugger display is correct. LPC55xx FLASH uses 0x00 as erased value, which is opposite to most of the other FLASH devices which use 0xFF as erased value) There is no way to verify the erased FLASH state with code in runtime. NXP enhanced LPC55xx FLASH with ECC added. This means that there is now a functional block between the read entity (for example the CPU) and the FLASH itself. When erasing, both the erased FLASH and its ECC are set as 0. The reading can’t be successful if the erased memory and its ECC don’t match. Thus we can’t read memory in erased state. AHB read hardfault error is produced if do so.  Because of ECC mechanism, you can't read FLASH until you have written to it. see   How to fix AHB Read HardFault Error The User's Manual mentions the reading and writing operation in UM11126 chapter 5.7.13: When writing, parity is automatically computed and stored alongside user data. When reading, data and parity are used to reconstruct correct data, even in the case of a 1-bit error. When reading an erased location, an uncorrectable error is flagged. Use the “blank check” command to test for successful erase. The LinkServer debug in MCUXpresso IDE takes some precautions to avoid this problem while programming the FLASH before starting a debug session. That’s the reason we can see erased memory state in debugger memory view window, Admittedly, this is something not really pre-eminent in the documentation. The only reference we could spot is in UM11126. See below: “ The selected pages are checked for the erased condition (all 0 including parity)”   Thanks for the valuable comment from Radu Theodor Lazarescu.
View full article
Overview          Ping-pong is a special case of a linked transfer which typically used more frequently than more complicated versions of linked transfers. A ping-pong transfer usually uses at least two buffers. At any one time, one buffer is being loaded or unloaded by DMA operations. The other buffers have the opposite operation being handled by software, readying the buffer for use when the buffer currently being used by the DMA controller is full or empty. The Fig 1 illustrates an example of descriptors for ping-pong from a peripheral to two buffers in memory. Fig 1 Implementation detail         To continuous transfer the converted result of the ADC to RAM, I’m going to use four 4 DMA descriptors to work in Ping-Pong mode to achieve this goal as the Fig 2 shows. Fig 2 Data flow via Ping-Pong mode Hardware introduction         LPCXpressor54114 Board ( OM13089 ) Fig 3 LPCXpressor54114 Board        Demo code: LPCOpen Library Example code        The code is based on the periph_adc demo, using the SCTimer output as the hardware trigger of ADC, meanwhile, the ADC converted value is transferred to the appointed area of RAM automatically. #include "board.h" #define SCT_PWM            LPC_SCT #define NUM_BUFFERS 4 #define DMA_TRANSFER_SIZE 8 #define ADC_INPUT_CHANNEL 1 #define SCT_PWM_RATE   10000          /* PWM frequency 10 KHz */ #define SCT_PWM_PIN_OUT    7          /* COUT7 Generate square wave */ #define SCT_PWM_OUT        1          /* Index of OUT PWM */ uint16_t adcOut ; ALIGN ( 512 ) DMA_CHDESC_T ADC_TransferDescriptors [ NUM_BUFFERS ] ; uint16_t CapturedData [ 32 ] ; uint16_t DMA_Sum = 0 ; /** * * ADC IRQ not Used right now... Only for testing */ void ADC_SEQA_IRQHandler ( void ) {             /* If SeqA flags is set i.e. data in global register is valid then read it */         Chip_GPIO_SetPinState ( LPC_GPIO , 0 , 6 , true ) ;         //DEBUGOUT("ADC Output = %d\r\n", adcOut);         Chip_GPIO_SetPinState ( LPC_GPIO , 0 , 6 , false ) ;         Chip_ADC_ClearFlags ( LPC_ADC , 0xFFFFFFFF ) ; } void DMA_IRQHandler ( void ) {         static uint16_t DMA_Sum = 0 ;                 DMA_Sum ++ ;                  if ( DMA_Sum == 8 )          {            DMA_Sum = 4 ;          }             Chip_GPIO_SetPinState ( LPC_GPIO , 0 , 7 , true ) ;      /* Rrror interrupt on channel 0? */      if ( ( Chip_DMA_GetIntStatus ( LPC_DMA ) & DMA_INTSTAT_ACTIVEERRINT ) != 0 )      {           /* This shouldn't happen for this simple DMA example, so set the LED              to indicate an error occurred. This is the correct method to clear              an abort. */           Chip_DMA_DisableChannel ( LPC_DMA , DMA_CH0 ) ;           while ( ( Chip_DMA_GetBusyChannels ( LPC_DMA ) & ( 1 << DMA_CH0 ) ) != 0 ) { }           Chip_DMA_AbortChannel ( LPC_DMA , DMA_CH0 ) ;           Chip_DMA_ClearErrorIntChannel ( LPC_DMA , DMA_CH0 ) ;           Chip_DMA_EnableChannel ( LPC_DMA , DMA_CH0 ) ;           Board_LED_Set ( 0 , true ) ;      }      Chip_GPIO_SetPinState ( LPC_GPIO , 0 , 7 , false ) ;      /* Clear DMA interrupt for the channel */      LPC_DMA -> DMACOMMON [ 0 ] . INTA = 1 ; }      /***       *      ____  __  __    _       *     |  _ \|  \/  |  / \       *     | | | | |\/| | / _ \       *     | |_| | |  | |/ ___ \       *     |____/|_|  |_/_/   \_\       *     / ___|  ___| |_ _   _ _ __       *     \___ \ / _ \ __| | | | '_ \       *      ___) |  __/ |_| |_| | |_) |       *     |____/ \___|\__|\__,_| .__/       *                          |_|       */ void DMA_Steup ( void ) {         DMA_CHDESC_T Initial_DMA_Descriptor ;                 ADC_TransferDescriptors [ 0 ] . source = ( uint32_t ) & LPC_ADC -> SEQ_GDAT [ 0 ] ;      ADC_TransferDescriptors [ 1 ] . source = ( uint32_t ) & LPC_ADC -> SEQ_GDAT [ 0 ] ;      ADC_TransferDescriptors [ 2 ] . source = ( uint32_t ) & LPC_ADC -> SEQ_GDAT [ 0 ] ;      ADC_TransferDescriptors [ 3 ] . source = ( uint32_t ) & LPC_ADC -> SEQ_GDAT [ 0 ] ;      ADC_TransferDescriptors [ 0 ] . dest = ( uint32_t ) & CapturedData [ ( 0 + 1 ) * DMA_TRANSFER_SIZE -1 ] ;      ADC_TransferDescriptors [ 1 ] . dest = ( uint32_t ) & CapturedData [ ( 1 + 1 ) * DMA_TRANSFER_SIZE -1 ] ;      ADC_TransferDescriptors [ 2 ] . dest = ( uint32_t ) & CapturedData [ ( 2 + 1 ) * DMA_TRANSFER_SIZE -1 ] ;      ADC_TransferDescriptors [ 3 ] . dest = ( uint32_t ) & CapturedData [ ( 3 + 1 ) * DMA_TRANSFER_SIZE -1 ] ;      //The initial DMA desciptor is the same as the 1st transfer descriptor.   It      //Will link into the 2nd of the main descriptors.      ADC_TransferDescriptors [ 0 ] . next = ( uint32_t ) & ADC_TransferDescriptors [ 1 ] ;      ADC_TransferDescriptors [ 1 ] . next = ( uint32_t ) & ADC_TransferDescriptors [ 2 ] ;      ADC_TransferDescriptors [ 2 ] . next = ( uint32_t ) & ADC_TransferDescriptors [ 3 ] ;      //Link back to the 1st descriptor      ADC_TransferDescriptors [ 3 ] . next = ( uint32_t ) & ADC_TransferDescriptors [ 0 ] ;      //For a test,  stop the transfers here.   The sine wave will look fine.      //ADC_TransferDescriptors[3].next = 0;      ADC_TransferDescriptors [ 0 ] . xfercfg = ( DMA_XFERCFG_CFGVALID |                                DMA_XFERCFG_RELOAD  |                                DMA_XFERCFG_SETINTA |                                DMA_XFERCFG_WIDTH_16 |                                DMA_XFERCFG_SRCINC_0 |                                DMA_XFERCFG_DSTINC_1 |                                DMA_XFERCFG_XFERCOUNT ( DMA_TRANSFER_SIZE ) ) ;      ADC_TransferDescriptors [ 1 ] . xfercfg = ADC_TransferDescriptors [ 0 ] . xfercfg ;      ADC_TransferDescriptors [ 2 ] . xfercfg = ADC_TransferDescriptors [ 0 ] . xfercfg ;      ADC_TransferDescriptors [ 3 ] . xfercfg = ( DMA_XFERCFG_CFGVALID |                                DMA_XFERCFG_RELOAD  |                                DMA_XFERCFG_SETINTA |                               DMA_XFERCFG_WIDTH_16 |                               DMA_XFERCFG_SRCINC_0 |                               DMA_XFERCFG_DSTINC_1 |                               DMA_XFERCFG_XFERCOUNT ( DMA_TRANSFER_SIZE ) ) ;      Initial_DMA_Descriptor . source = ADC_TransferDescriptors [ 0 ] . source ;      Initial_DMA_Descriptor . dest =    ADC_TransferDescriptors [ 0 ] . dest ;      Initial_DMA_Descriptor . next =   ( uint32_t ) & ADC_TransferDescriptors [ 1 ] ;      Initial_DMA_Descriptor . xfercfg = ADC_TransferDescriptors [ 0 ] . xfercfg ;      /* DMA initialization - enable DMA clocking and reset DMA if needed */      Chip_DMA_Init ( LPC_DMA ) ;      /* Enable DMA controller and use driver provided DMA table for current descriptors */      Chip_DMA_Enable ( LPC_DMA ) ;      Chip_DMA_SetSRAMBase ( LPC_DMA , DMA_ADDR ( Chip_DMA_Table ) ) ;      /* Setup channel 0 for the following configuration:         - High channel priority         - Interrupt A fires on descriptor completion */      Chip_DMA_EnableChannel ( LPC_DMA , DMA_CH0 ) ;      Chip_DMA_EnableIntChannel ( LPC_DMA , DMA_CH0 ) ;      Chip_DMA_SetupChannelConfig ( LPC_DMA , DMA_CH0 ,      //(DMA_CFG_PERIPHREQEN     |                                    ( DMA_CFG_HWTRIGEN        |                                     DMA_CFG_TRIGBURST_BURST |                                                          DMA_CFG_TRIGTYPE_EDGE   |                                        DMA_CFG_TRIGPOL_LOW    |     //DMA_CFG_TRIGPOL_HIGH                                        DMA_CFG_BURSTPOWER_1    |                                     DMA_CFG_CHPRIORITY ( 0 )                                          )                                        ) ;      //make sure ADC Sequence A interrupts is selected for for a DMA trigger      LPC_INMUX -> DMA_ITRIG_INMUX [ 0 ] = 0 ;      /* Enable DMA interrupt */      NVIC_EnableIRQ ( DMA_IRQn ) ;      // The 1st descriptor is set up through the registers.      /* Setup transfer descriptor and validate it */      Chip_DMA_SetupTranChannel ( LPC_DMA , DMA_CH0 , & Initial_DMA_Descriptor ) ;      //Use the transfer configuration for our 4 main descriptors      Chip_DMA_SetupChannelTransfer ( LPC_DMA , DMA_CH0 ,      ADC_TransferDescriptors [ 0 ] . xfercfg ) ;      Chip_DMA_SetValidChannel ( LPC_DMA , DMA_CH0 ) ;       } void SCT_PWM_Generate ( void ) {          /* Initialize the SCT as PWM and set frequency */      Chip_SCTPWM_Init ( SCT_PWM ) ;      Chip_SCTPWM_SetRate ( SCT_PWM , SCT_PWM_RATE ) ;      /* Setup Board specific output pin */      Chip_IOCON_PinMuxSet ( LPC_IOCON , 1 , 14 , IOCON_FUNC3 | IOCON_MODE_INACT | IOCON_DIGITAL_EN | IOCON_INPFILT_OFF ) ;      /* Use SCT0_OUT7 pin */      Chip_SCTPWM_SetOutPin ( SCT_PWM , SCT_PWM_OUT , SCT_PWM_PIN_OUT ) ;              /* Start with 50% duty cycle */      Chip_SCTPWM_SetDutyCycle ( SCT_PWM , SCT_PWM_OUT , Chip_SCTPWM_PercentageToTicks ( SCT_PWM , 10 ) ) ;      Chip_SCTPWM_Start ( SCT_PWM ) ;     }      /***            *         _    ____   ____            *        / \  |  _ \ / ___|            *       / _ \ | | | | |            *      / ___ \| |_| | |___            *     /_/__ \_\____/ \____|            *     / ___|  ___| |_ _   _ _ __            *     \___ \ / _ \ __| | | | '_ \            *      ___) |  __/ |_| |_| | |_) |            *     |____/ \___|\__|\__,_| .__/            *                          |_|            */ void ADC_Steup ( void ) {     /*Set Asynch Clock to the Main clock*/     LPC_SYSCON -> ADCCLKSEL = 0 ;     //Set the divider to 1 and enable.  note,  the HALT bit (30) and RESET (29) are not in the manual     LPC_SYSCON -> ADCCLKDIV = 0 ;      /* Initialization ADC to 12 bit and set clock divide to 1 to operate synchronously at System clock */     Chip_ADC_Init ( LPC_ADC , ADC_CR_RESOL ( 3 ) | ADC_CR_CLKDIV ( 0 ) | ADC_CR_ASYNC_MODE ) ;        //select ADC Channel 1 as input     Chip_IOCON_PinMuxSet ( LPC_IOCON , 0 , 30 , IOCON_FUNC0 | IOCON_ANALOG_EN | IOCON_INPFILT_OFF ) ;        LPC_ADC -> INSEL = 0x01 ;     Chip_ADC_SetupSequencer ( LPC_ADC , ADC_SEQA_IDX ,                                                                           ADC_SEQ_CTRL_SEQ_ENA |                               ADC_SEQ_CTRL_CHANNEL_EN ( ADC_INPUT_CHANNEL ) |                                                 ADC_SEQ_CTRL_TRIGGER ( 2 ) |                               ADC_SEQ_CTRL_HWTRIG_POLPOS |                                                 ADC_SEQ_CTRL_HWTRIG_SYNCBYPASS |                               ADC_SEQ_CTRL_MODE_EOS |                                                 ADC_SEQ_CTRL_SEQ_ENA ) ;     /* Enable Sequence A interrupt */     Chip_ADC_EnableInt ( LPC_ADC , ADC_INTEN_SEQA_ENABLE ) ;         /* Calibrate ADC */     if ( Chip_ADC_Calibration ( LPC_ADC ) == LPC_OK ) {         /* Enable ADC SeqA Interrupt */         NVIC_EnableIRQ ( ADC_SEQA_IRQn ) ;     }     else {         DEBUGSTR ( "ADC Calibration Failed \r\n" ) ;         return ;     } } int main ( void ) {       SystemCoreClockUpdate ( ) ;     Board_Init ( ) ;         DMA_Steup ( ) ;     ADC_Steup ( ) ;     SCT_PWM_Generate ( ) ;         while ( 1 )     { }     } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍  Verification      Building the project, then click the   to debug;        Generate the sine wave: 1 KHz, 幅度:0~2 V,feed the wave the ADC via the J9_1(P0_30-ADC1);         Setting the breakpoint (Fig 4) to observe the ADC converted value CapturedData[32]; Fig 4                        4. To verifying the result, I collect several group of data and use the Excel to make these data graphical for checking. Fig 6 is an example. Fig 5 Fig 6 Fig 7 Fig 8
View full article
NXP’s Arm® Cortex®-M33 based LPC551x MCU Family Enhanced Security & Performance Efficiency
View full article
The LPC800 series is a 32-bit, Arm® Cortex®-M0+-based MCU portfolio offering a range of low-power, space efficient, low-pin-count options for basic microcontroller applications. Unique among low-end devices, the LPC800 series MCUs include differentiated product features, such as an NFC communication interface, programmable logical unit (PLU), mutual capacitive touch, switch matrix for flexible configuration, patent-approved SCTimer/PWM, and more – including a comprehensive enablement offering to help you get to market faster. LPC80x 15 MHz|Arm Cortex-M0+|32-bit Microcontrollers (MCUs)|NXP  Webinar series are now available for on-demand viewing, you can get access to the webinars by clicking on the following links:   (5/31) Part I: Thinking about migrating from 8-bit? Wait no longer - LPC80x MCUs are your 32-bit answer! Learn more about the LPC80x MCU family, discover the features, target applications, tools, software and how to get started right away with your 32-bit design.   (6/07) Part II: Creative ways to leverage the LPC804 MCU’s integrated programmable logic feature Continuing its history of innovation in MCUs, NXP introduces a programmable logic unit (PLU) to the LPC family for the first time with the LPC804 MCU. We'll show you how easy it is set up the PLU as we will explore several real-world examples of the challenges many face, but can be overcome with this unique feature.   (6/14) Part III: Get started fast with this comprehensive enablement offering for LPC800 MCUs In May 2018, NXP expanded the MCUXpresso suite of software and tools to include full support for the LPC800 MCU family. Learn about the MCUXpresso IDE, configuration tools and SDK support that is now available for the most cost-effective and compelling family of Arm-based 8-bit replacement microcontrollers available.   (6/21) Part IV: Got NFC? LPC8N04 does - Learn how to leverage this unique feature in your next design? Learn more about the LPC8N04 MCU, its features, and how to get started with NFC quickly by leveraging the available development   Presentations for the webinars are also available now!
View full article
MCUXpresso Config Tools is now available! You can access it on the following link: Welcome to MCUXpresso | MCUXpresso Config Tools  Overview. MCUXpresso Config Tools provides a set of system configuration tools that help users of all levels with a Kinetis or LPC-based MCU solution. Let it be your guide from first evaluation to production development. High Quality, Comprehensive Enablement - Production-grade, rigorously tested software and tools. - Easy-to-use SDK, IDE and configuration tools. Compatibility Across MCUs - Supports Kinetis, LPC Cortex-M. - Easy migration and scalability between MCUs. Note: i.MX Cortex-M device support coming in 2017 Interoperability Across Tools - Common experience and broader support through fewer, more cohesive software and tools. - Seamless development using SDK, IDE and Config tools together. - SDK and configuration tools also support the large ecosystem of NXP’s partner IDEs. Features. Architecture - CMSIS-CORE compatible - Single driver for each peripheral - Transactional APIs w/ optional DMA support for communication peripherals Integrated RTOS - FreeRTOS, µC/OS-II & -III - RTOS-native driver wrappers Integrated Stacks and Middleware - USB Host, Device and OTG - lwIP, FatFS - Crypto acceleration plus wolfSSL & mbedTLS - SD and eMMC card support Reference Software - Peripheral driver usage examples - Application demos - FreeRTOS usage demos License - BSD 3-clause for startup, drivers, USB stack Toolchains - IAR®, ARM® Keil®, GCC w/ Cmake - + MCUXpresso IDE Quality - Production-grade software - MISRA 2004 compliance - Checked with Coverity® static analysis tools C onfiguration and development tools .   SDK Builder packages custom SDKs based on user selections of MCU, evaluation board, and optional software components. Pins, Clocks, and Peripheral (1) tools generate initialization C code for custom board support. Project Generator (1) creates new SDK projects  or clones existing ones. Power Estimation tool provides energy and battery-life estimates based on a user’s application model Power Analyzer (1) measures and displays energy consumption data . (1)Coming 2017 Related links: Introducing MCUXpresso SDK v.2 for LPC54xxx Series  Generating a downloadable MCUXpresso SDK v.2 package  How to start with SDK v.2.0 for LPC5411x using LPCXpresso IDE  https://community.nxp.com/docs/DOC-333369   
View full article
#lpc‌ #dualcore‌ #feature‌ Attached doc is the LPC MCU Serial dual core feature introduction and application
View full article
Now that you've downloaded & unzipped your LPCXpresso54608 SDK, let's open KEIL  uVision IDE. Note: you must have at least uVision version 5.22.0.0 to use this board Before we start utilizing uVision we must make sure that we have the relevant packs installed to work with the LPCXpresso54608 board. Select the Pack Installer on the toolbar. The Pack installer shows you which parts and boards for which you have support. On the left hand side you see a variety of different manufacturers. The easiest way to search will be to type 'lpc' into the search right below the devices tab. Then select 'LPC54000 Series'. On the right hand side under the packs tab you will see one item listed under 'Device Specific' called 'Keil::LPC54000_DFP' click on install Note: Version 2.1.0 released on 10-18-2016 added LPC5460x support. If you had downloaded this pack before go to Packs>Check for Updates at the top to download the latest version Once installed the diamond will turn green. To double check we are ready, select boards on the left side and search  'lpcxpresso54'. You will notice that our board is green indicating we have support for it in uVision. Now we can close the Pack Installer to return to uVision Select File>Open and navigate to the location you unzipped your SDK download.  By the way, within this folder there are plenty of SDK based demos for you to explore our microcontroller.  We will use one of them to guide you through this tutorial, but definitely take time to try all of them! Navigate to boards>lpcxpresso54608>demo_apps>touch_cursor>mdk, change file type to ''Project Files (*.uvproj, *.uvprojx) and select 'touch_cursor' Once opened, select 'Build' right above the Project window. Once the Build Output window tells you that you have successfully built the program select the 'Start/Stop Debug Session' icon. Note: You may receive a warning if you have a size limitation on the license you are using. If you do get a warning you can resolve licensing issues by going to File>License Management. Once the debug session has been started select 'Run' on the left side Once you have successfully flashed the board with this demo you will see the following, This demo utilizes the touch interface on the screen to read where you are touching and updates the cursor position to the last known location.   Remember that other demos and sample code are provided in the root folder of the SDK download.   Be sure to explore these demos and reach out on the community if you need help!
View full article
In this document, I will explain how to create a project to use the SPIFI library version 1.03 with the LPC4370. For this we will need the following tools: MCUXpresso IDE 10.2. Link LPC-LINK2 to use it as an evaluation board for the LPC4370. Link External debugger. In my case, I used another LPC-LINK2 board. LPCOpen v2_12 for the LPC4370, this version comes with the installation of MCUXpresso IDE. SPIFI library v1.3. Link Code Example lpcopen_2_12_lpcxpresso_ngx_xplorer_1830_SPIFI_v1.0. Link First, download and install all the tools needed. In your workspace of MCUXpresso we will import (1) three projects of the LPCOpen v2_12 for the LPC4370: periph_blinky, lpc_board_nxp_lpclink2_4370 and lpc_chip_43xx.  The LPCOpen zip file is in the next path of your PC: C:\nxp\MCUXpressoIDE_10.2.1_795\ide\Examples\LPCOpen (2) Extract the files of the zip named lpclibspifi_lpcxpresso_1.03_68 that we downloaded before. The folder that we need is spifilib_m4f. Drag and drop this folder into the Project Explorer on your workspace of the LPC4370, after choosing copy and you should see the spifilib_m4f in your Project Explorer. Once you imported correctly the SPIFI library, select the library (1) on the project explorer window and build it (2) . Once you do this you should see that a new folder called Debug appear (3) . Now we need to edit the properties of the periph_blinky example to add the library spifilib_m4f to the project. To do this, right click on the project and click properties. Once in the properties window click on C/C++ Build (1) > Settings (2) > Includes (under the section MCU C Compiler) (3) . In the includes window click Add… (1) > Workspace (2) > spifilib_m4f (3) > inc (4) > click OK (5) on the window Folder Selection > click OK (6) on the window Add directory path. You should see the following on the include paths. Now, go to the libraries (1) option under the section MCU Linker, on the section Libraries (-I) click Add… (2) finally write the name of the library (spifilib_m4f) (3) and click OK (4) . Under the section Library search path (-L) click Add… (1) > Workspace (2) > spifilib_m4f (3) > Debug (4) > OK (5) . If you see the same as shown in the below image you are good to go so click Apply and close. To check if you did the below steps correct let’s do the following. On the project periph_blinky in the file systick.c include the file spifilib_api.h and compile the project. If the project compiles without problems it means that you imported correctly the spifi library. If you found problems please stop and repeat all the steps mentioned before. Now that we added successfully the library we can start to migrate the example for the LPC1830 that we download before. First, unzip the file lpcopen_2_12_lpcxpresso_ngx_xplorer_1830_SPIFI_v1.0. Once you unzipped the file go to the following path: spifilib_blinky > example > src. Open the file named Blinky.c and copy all the content of the file. Now go to the file systick.c on your workspace of MCUXpresso within the project periph_blinky, delete all the content of this file and paste what you copied before. Do not compile at this point or you will receive multiple errors! Go back to the path spifilib_blinky > example > src on your PC. Drag and drop the file called spifi_setup.c into the folder src of your project periph_blinky on your Workspace. Open the file that we just copy into our workspace and go to line 46 of the code. Here we are creating a buffer of 64KB that we will use later to write in the SPIFI. The __BSS(RAM3) is to save this buffer in the RAM block three of memory. The problem here is that the block of RAM3 in the LPC4370 is not big enough to store the buffer of 64KB (see below image), so let’s change this for either RAM or RAM2 that are big enough to store the buffer. Now that we added the spifi_setup file let’s go back to the systick.c file and add the external declaration for the function spifiSetUp. At this point, if we compile the project we shouldn’t see any problems, only some warnings because of the functions and variables that we are not using. We are almost done, we are missing the most important thing. With this demo you will be writing, deleting and reading the SPIFI memory, this means that you cannot be executing form the SPIFI flash memory. You need to move to the RAM memory all the functions that are going to make this. This is the reason why in the file systick.c we don’t have any function that interacts directly with the SPIFI, this will make much easier the work of moving all the functions that interact with the SPIFI memory to RAM. The function spifiSetUp is the one that will make all the tests on the SPIFI and it is in the spifi_setup file, so we will need to move this entire file to RAM along with the SPIFI library. We will use three different scripts to move the library and the file spifi_setup to RAM. You can learn more about this in the following community post: https://community.nxp.com/thread/389110. First, right click on the folder of the project > new > folder, the name of the folder must be linkscripts. According to the sections Relocating particular objects into RAM and Relocating particular libraries into RAM of the community post mentioned before we need to create three files in this new folder: main_text.ldt, main_rodata.ldt and main_data.ldt. To do this, right click on the folder linkscripts > new > file. Here is the content that you should have on the three files that we just created. Do not include on the files the text that is in bold, that's just for reference! File main_data.ldt *libspifilib_m4f.a:(.text*) *libspifilib_m4f.a:(.rodata .rodata.* .constdata .constdata.*) *spifi_setup.o(.text*) *spifi_setup.o(.rodata .rodata.* .constdata .constdata.*) . = ALIGN(${text_align}); *(.data*) File main_rodata.ldt *(EXCLUDE_FILE(*libspifilib_m4f.a: *spifi_setup.o) .rodata) *(EXCLUDE_FILE(*libspifilib_m4f.a: *spifi_setup.o) .rodata.*) *(EXCLUDE_FILE(*libspifilib_m4f.a: *spifi_setup.o) .constdata) *(EXCLUDE_FILE(*libspifilib_m4f.a: *spifi_setup.o) .constdata.*) . = ALIGN(${text_align}); File main_text.ldt *(EXCLUDE_FILE(*libspifilib_m4f.a: *spifi_setup.o) .text*) After finishing with the three files you are done with the demo! It’s important to mention that if you want to go inside the function spifiSetUp while debugging you need to set a breakpoint inside the function. While debugging we can see that before calling the function spifiSetUp we are running from the SPIFI flash memory and once we enter to the function we are running from RAM memory. Once we run the demo successfully we should see the following in a terminal and the LED1 will be blinking. Hope this guide is helpful! Best Regards, Victor.
View full article