Live at Computex 2018 this week is: The High Performance Gaming Mouse Controlling Hundreds of Full Color LEDs Powered by LPC51U68 A 100MHz Arm® Cortex®-M0+ delivering real-time response for game player 96K SRAM for LED pattern allows for a smooth transition  Built-in USB drivers in ROM and supports 1K report rate 8 Flexcomm serial channels to drive up to 800 LEDs with full color control at the same time

LPCXpresso54608 development board up and running out of the box with our unified software development kit (SDK)!

[中文翻译版] 见附件 原文链接： https://community.nxp.com/docs/DOC-343506

This is a quick introduction that shows how to interface the LPC845 Breakout Board with an OLED display based on the popular SSD1306 controller, using SDK drivers for SPI. With this application, you can print a text string or draw a bitmap image.   SPI Protocol The Serial Peripheral Interface (SPI) protocol is asynchronous serial data standard, primarily used to allow a microprocessor to communicate with other microprocessors or ICs such as memories, liquid crystal diodes (LCD), analog-to-digital converter subsystems, etc.   The SPI is a very simple synchronous serial data, master/slave protocol based on four lines:       • Clock line (SCLK)       • Serial output (MOSI)       • Serial input (MISO)       • Slave select (SS)   Adafruit Monochrome OLED Graphical Display This display is made of 128x64 individual white OLED pixels, each one is turned on or off by the controller chip. Because the display makes its own light, no backlight is required. This reduces the power required to run the OLED and is why the display has such high contrast; we really like this miniature display for its crispness!     OLED Display Example NXP provides an example package for the LPC845 Breakout that includes projects to use the principal's peripherals that the board include: ADC, I2C, PWM, USART, Captouch, and SPI   What we need: LPC845 Breakout Board MCUXpresso IDE V10.3.0 SDK_2.5.0_LPC845 NXP example package OLED Display from Adafruit (also available via NXP distributors) LCD assistant software to convert bitmaps Micro USB cable   Once downloaded, we import the library project into the workspace using the ''Import project(s) from file system... from the Quickstart panel in MCUXpresso IDE: Figure 1. Import Projects.   Then browse the examples packages archive file: Figure 2. Select Example Package.   Press next, and see that are a selection of projects to import, in this case, only keep select the LPC845_BoB_OLED how it looks in the picture below: Figure 3. Select the OLED Project.   Press finish and the project example shows up in the workspace: Figure 4. OLED Project in workspace. Create Bitmaps Bitmap (BMP) is an image file format that can be used to create and store computer graphics. A bitmap file displays a small dots in a pattern that, when viewed from afar, creates an overall image. A bitmap image is a grid made of rows and columns where a specific cell is given a value that fills it in or leaves it blank, thus creating an image out of the data. First, you have to create the image using any kind of graphics software such a paint, Photoshop, etc and save the picture as Monochrome Bitmap (bmp), make sure that the image size match whit the OLED size.       Figure 5. Save picture as Bitmap.   Now inside the LCD software assistant, this program will help us to convert an image from Bitmap to data array, we have to load the image by click on file >> load image, and select the appropriate size.   Figure 6. LCD Assistant    To import the array go to file >> save the output, choose the place where are going to save. Then inside the example, go to fsl_Font5x7.h and paste the array.   Figure 7. Data Array.      *Note: Inside the example, the array for the NXP logo is already there, if you want another image, delete this array and pas the new.   Connections Now, with the project already in the workspace, it is time to set up the connection between the LPC845 Breakout board and the OLED Display. The table below shows which LPC845 Breakout pin are routed each line of the SPI interface and the pins for reset and Data/Command select.   Table 1. Connections.   You can check the Datasheet of the board, of bases on the picture below to see where the pin are, note that GND and 3.3V also needed for the OLED display: Figure 8. LPC845 Breakout to OLED Connection.   Debug. Now, with the demo in the workspace and the connections done, connect a micro USB cable from connector CN2 to a host computer and debug the application.   Figure 9. Run example

LWIP debug output or application messages can be routed out to one of the serial ports by configuring the debug options. Enabling debug output in LWIP To enable debug code in LWIP, the "LWIP_DEBUG" flag needs to be defined when compiling the LWIP code. This can usually be done by using the "-D" option to define the flag as part of the argument list for the compiler. For example in the Keil tools, you can add the define C/C++ tab of the target options dialog. To enable specific debug messages in LWIP, just set the specific define value for the LWIP *_DEBUG value to " LWIP_DBG_ON". A full list of debug defines that can be enabled can be found in the opts.h file. Just copy the defines for the debug messages you want to enable into the lwipopts.h file for your project and enable them there. A few examples are shown below. #define TCP_DEBUG                       LWIP_DBG_ON #define ETHARP_DEBUG                    LWIP_DBG_ON #define PBUF_DEBUG                      LWIP_DBG_ON Selecting debug output The UART channel used for debug outputcan be selected by setting the UART_REDIRECT define to the UART number. On the LPC177x_8x devices, setting this to 0, 1, or 2 will enable output for UART ports 0, 1, or 2, respectively. You can completely disable output (while keep the debug code inside LWIP) by setting UART_REDIRECT to -1. As of release v1.01, simply enabling LWIP_DEBUG as the compilation define will automatically select the right UART for debug output. You can still override the UART for output if needed, but will need to edit the UART in the debug framework file. Caveats of enabling debug output Enabling debug output can add significant size to the generated code based on the debug options selected for the build. It will also slow down performance of the LWIP code due to required run-time checks and output. It's is recommended to enable debug support only if needed. Enabling just the UART for debug output adds about 4KBytes to the code size and about 512 bytes to the data size. The UART driver uses a ring buffer for buffering debug output with the UART IRQ to feed that data to the UART. The ring buffer size can be changed by changing the "UART_RING_BUFSIZE" define value in the serial.c file. Note: The call to initialize the debug framework used for LWIP debug output and printf() is active in the examples by default. Just remove the call to debug_frmwrk_init() in the examples to save some additional code and data memory. You may have also to remove the redirect.c file from the project for this change. Enabling debug output in the LWIP code uses a varying amount of memory based on which LWIP *_DEBUG defines are enabled. Without LWIP debug output enabled and the options selected below, the code size is increased by an additional 23.5KBytes and the data size increased by 1.6KBytes. #define LWIP_DEBUG #define TCP_DEBUG                       LWIP_DBG_ON #define ETHARP_DEBUG                    LWIP_DBG_ON #define PBUF_DEBUG                      LWIP_DBG_ON #define IP_DEBUG                        LWIP_DBG_ON #define TCPIP_DEBUG                     LWIP_DBG_ON #define DHCP_DEBUG                      LWIP_DBG_ON #define UDP_DEBUG                       LWIP_DBG_ON Note memory usage was checked at the 'default' compiler optimization setting. Example debug output Some example debug output use for capturing TCPIP, ethernet ARP, PBUF allocaiton and de-allocation, etc. are shown in the example output below captured from a LWIP run. Ethernet link not yet detected, will continue Starting LWIP ping server... dhcp_start(netif=1000eddc) en0 dhcp_start(): starting new DHCP client dhcp_start(): allocated dhcpudp_bind(ipaddr = 0.0.0.0, port = 68) udp_bind: bound to 0.0.0.0, port 68 udp_connect: connected to 0.0.0.0,port 68 dhcp_start(): starting DHCP configuration dhcp_discover() pbuf_alloc(length=308) pbuf_alloc(length=308) == 200018b4 transaction id xid(abcd0001) dhcp_discover: making request dhcp_discover: realloc()ing dhcp_discover: sendto(DISCOVER, IP_ADDR_BROADCAST, DHCP_SERVER_PORT) pbuf_header: old 200018fc new 200018f4 (8) udp_send: added header in given pbuf 200018b4 udp_send: sending datagram of length 316 udp_send: UDP packet length 316 udp_send: UDP checksum 0xdee0 udp_send: ip_output_if (,,,,IP_PROTO_UDP,) pbuf_header: old 200018f4 new 200018e0 (20) ip_output_if: en0 IP header: +-------------------------------+ | 4 | 5 |  0x00 |       336     | (v, hl, tos, len) +-------------------------------+ |        0      |000|       0   | (id, flags, offset) +-------------------------------+ |  255  |   17  |    0xba9d     | (ttl, proto, chksum) +-------------------------------+ |    0  |    0  |    0  |    0  | (src) +-------------------------------+ |  255  |  255  |  255  |  255  | (dest) +-------------------------------+ netif->output()pbuf_header: old 200018e0 new 200018d2 (14) etharp_send_ip: sending packet 200018b4 dhcp_discover: deleting()ing pbuf_free(200018b4) pbuf_free: deallocating 200018b4 dhcp_discover: SELECTING dhcp_discover(): set request timeout 2000 msecs tcp_bind: bind to port 7 dhcp_discover() pbuf_alloc(length=308) pbuf_alloc(length=308) == 200018b4 transaction id xid(abcd0002) dhcp_discover: making request dhcp_discover: realloc()ing dhcp_discover: sendto(DISCOVER, IP_ADDR_BROADCAST, DHCP_SERVER_PORT) pbuf_header: old 200018fc new 200018f4 (8) udp_send: added header in given pbuf 200018b4 udp_send: sending datagram of length 316 udp_send: UDP packet length 316 udp_send: UDP checksum 0xdde0 udp_send: ip_output_if (,,,,IP_PROTO_UDP,) pbuf_header: old 200018f4 new 200018e0 (20) ip_output_if: en0 IP header: +-------------------------------+ | 4 | 5 |  0x00 |       336     | (v, hl, tos, len) +-------------------------------+ |        1      |000|       0   | (id, flags, offset) +-------------------------------+ |  255  |   17  |    0xba9c     | (ttl, proto, chksum) +-------------------------------+ |    0  |    0  |    0  |    0  | (src) +-------------------------------+ |  255  |  255  |  255  |  255  | (dest) +-------------------------------+ netif->output()pbuf_header: old 200018e0 new 200018d2 (14) etharp_send_ip: sending packet 200018b4 dhcp_discover: deleting()ing pbuf_free(200018b4) pbuf_free: deallocating 200018b4 dhcp_discover: SELECTING dhcp_discover(): set request timeout 2000 msecs etharp_request: sending ARP request. pbuf_alloc(length=42) pbuf_alloc(length=42) == 200018b4 etharp_raw: sending raw ARP packet. pbuf_free(200018b4) pbuf_free: deallocating 200018b4 pbuf_alloc(length=594) pbuf_alloc(length=594) == 20004cc0 ethernet_input: dest:00:60:37:12:34:56, src:00:26:f3:a2:6b:b2, type:800 pbuf_header: old 20000050 new 2000005e (-14) ip_input: iphdr->dest 0x1d0a010a netif->ip_addr 0x0 (0x0, 0x0, 0x1d0a010a) ip_input: UDP packet to DHCP client port 68 ip_input: DHCP packet accepted. ip_input: IP header: +-------------------------------+ | 4 | 5 |  0x00 |       576     | (v, hl, tos, len) +-------------------------------+ |        0      |000|       0   | (id, flags, offset) +-------------------------------+ |   64  |   17  |    0x508e     | (ttl, proto, chksum) +-------------------------------+ |   10  |    1  |   10  |    1  | (src) +-------------------------------+ |   10  |    1  |   10  |   29  | (dest) +-------------------------------+ ip_input: p->len 576 p->tot_len 576 pbuf_header: old 2000005e new 20000072 (-20) udp_input: received datagram of length 556 UDP header: +-------------------------------+ |        67     |        68     | (src port, dest port) +-------------------------------+ |       556     |     0x8880    | (len, chksum) +-------------------------------+ udp (10.1.10.29, 68) <-- (10.1.10.1, 67) udp_input: calculating checksum pbuf_header: old 20000072 new 2000007a (-8) dhcp_recv(pbuf = 20004cc0) from DHCP server 10.1.10.1 port 67 pbuf->len = 548 pbuf->tot_len = 548 searching DHCP_OPTION_MESSAGE_TYPE DHCP_OFFER received in DHCP_SELECTING state dhcp_handle_offer(netif=1000eddc) en0 dhcp_handle_offer(): server 0x010a010a dhcp_handle_offer(): offer for 0x1d0a010a dhcp_select(netif=1000eddc) en0 pbuf_alloc(length=308) pbuf_alloc(length=308) == 200018b4 transaction id xid(abcd0003) pbuf_header: old 200018fc new 200018f4 (8) udp_send: added header in given pbuf 200018b4 udp_send: sending datagram of length 316 udp_send: UDP packet length 316 udp_send: UDP checksum 0x9958 udp_send: ip_output_if (,,,,IP_PROTO_UDP,) pbuf_header: old 200018f4 new 200018e0 (20) ip_output_if: en0 IP header: +-------------------------------+ | 4 | 5 |  0x00 |       336     | (v, hl, tos, len) +-------------------------------+ |        2      |000|       0   | (id, flags, offset) +-------------------------------+ |  255  |   17  |    0xba9b     | (ttl, proto, chksum) +-------------------------------+ |    0  |    0  |    0  |    0  | (src) +-------------------------------+ |  255  |  255  |  255  |  255  | (dest) +-------------------------------+ netif->output()pbuf_header: old 200018e0 new 200018d2 (14) etharp_send_ip: sending packet 200018b4 pbuf_free(200018b4) pbuf_free: deallocating 200018b4 dhcp_select: REQUESTING dhcp_select(): set request timeout 2000 msecs pbuf_free(20004cc0) pbuf_free: 20004cc0 has ref 1, ending here. pbuf_free(20004cc0) pbuf_free: deallocating 20004cc0

DALI Software Development Kit The DALI development kits for LPC are no longer available. The LPC MCUs used are still available. This page is provided for reference purposes only. The DALI Software Development Kit (SDK) for the LPC11xx/LPC13xx contains an updated DALI Library for compliancy with the IEC 62386-102 and IEC 62386-201 standard. Parts of the IEC 62386-207 specification are also included. The DALI slave (AN11174 with OM13026 board) and the USB to DALI master (AN11175 with OM13046 board) can be used in combination with the Windows 7 PC GUI to create a demonstration and evaluation setup as described in UM10553. The SDK contains the example software, DALI library, a hardware description and design files of both boards, documentation and is available for download at the end of this document. DALI Slave OM13026                                                       DALI Master OM13046 System notes Controller side: The LPC1100XL (up to 50 MHz - 45 DMIPS) offers enough performance to integrate DALI 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 DALI 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 DALI Slave Implementation example (OM13026 board): Contains isolated physical layer for the DALI bus with a Cortex M0 LPC111x microcontroller for the DALI protocol handling, and many I/O functions to steer external lighting drivers for solid state or compact fluorescent lighting applications Schematics, gerbers and BOM also available to speed up development Up to four PWM signals available to independently drive different lighting units Frequency and resolution of the signals is software programmable ON_OFF signal can be used independently from the PWM signals to switch a lighting driver into an OFF or ON state I2C-bus pins can be used to externally connect other devices like EEPROM or a temperature sensor Analog A/D input is available via pin 8 IO signal is left open for the end user UART, I2C and A/D converter functionality not included in the software release

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

The Economist Intelligence Unit’s (EIU) 2020 IoT Index recently highlighted that 2020 will be the year when the Internet of Things (IoT) officially moves from “proof of concept” to “mass deployment”, with over half of all companies surveyed now undergoing early or extensive deployment of internal or external IoT networks. Read more >> NXP and Arm Pelion Device Management Secure Deployment of IoT Devices from Chip to Cloud | Pelion IoT Blog 

View Webinar Recording

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‌

This content was originally contributed to lpcware.com by Brewster LaMacchia   This project shows how to take the filter coefficients created by MDS' QEDesign filter design package and use them for real time audio filtering using the floating point DSP capability of the LPC4350. It's designed to run on the Hitex board and uses the UDA1380 for analog stereo I/O. It also uses the touch buttons, COG LCD, and LEDs for controlling operation.   Keil's Logic Analyzer tool was used for performance measurement. For full details see \doc\gen\html\index.html after unzipping the download.   Updated 16-Mar-12 to correct output rolloff in the UDA1380 due to the deemphasis filter being on by mistake.   Original Attachment has been moved to: MyProj.zip

When we use LPC55Sxx PRINCE feature, we need enable PRINCE sub-region “crypto” by setting SR_ENABLE register. If we “crypto” enable discontinuous sub-regions and erase part of them, we may find we can’t erase/read/write other “crypto” sub-regions any more. This article will discuss how to resolve this phenomenon.           Figure 1         Testing Steps According to LPC55Sxx UM, each PRINCE region has its SR_ENABLEx register. This register enables PRINCE encryption and decryption of data for each sub-region of crypto region 0. Each bit in this field enables a sub-region of crypto region 0 at offset 8kB*n, where n is the bit number.  For example, when we set SR_ENABLE0=0X00000005, PRINCE region 0 sub-region 1 and sub-region 3 are set as encryption region. When read data out from these sub-regions, PRINCE will decrypt the data automatically.   Now we will test discontinuous sub-region erase/read/write. Board: LPC55S16-EVK IDE: Keil MDK v5.29 Step 1: PRINCE initialization: Enable PRINCE region 0 and two discontinuous sub-regions; generate key, IV code; enable crypto. //set SR_ENABLE，SR_ENABLE=0X28000000,enable sub-regions(0x30000-0x32000,0x34000-0x36000) crypto。 status=PRINCE_SetRegionSREnable(PRINCE(prince_region_t)region0,0X28000000); //select PRINCE crypto for region0 PRINCE_SetRegionBaseAddress(PRINCE_Type*base,prince_region_tregion0,uint32_t0X0) //generate PRINCE region0 crypto key Status=FFR_KeystoreGetKC(&flashInstance,&keyCode[0],kFFR_KeyTypePrinceRegion0); status=PUF_GetHwKey(PUF,keyCode,sizeof(keyCode),kPUF_KeySlot2, rand()); //generate PRINCE region0 crypto IV_code status=PRINCE_GenNewIV(kPRINCE_Region0,&prince_iv_code[0],true,&flashInstance) //load IV code to PRINCE status=PRINCE_LoadIV(kPRINCE_Region0,&prince_iv_code[0]) //enable PRINCE encryption PRINCE_EncryptEnable(PRINCE)   Step 2: Select two discontinuous sub-regions ( 0x30000-0x32000,0x34000-0x36000). Erase one of them (0x30000-0x32000), then write data to this sub-region. Output: Erasing and Writing are all successful. See Figure 2. //Erase 0x30000-0x32000 sub-region status=PRINCE_FlashEraseWithChecker(&flashInstance,0x30000,0x2000,kFLASH_ApiEraseKey); //Write 0x30000-0x32000 sub-region status=PRINCE_FlashProgramWithChecker(&flashInstance,0x30000,(uint8_t *)prince_iv_code,0x2000);   Step 3: Erase and Write the other sub-region ( 0x34000-0x36000 ) Output: Erasing and Writing are failed. See Figure 2. //Erasing 0x34000-0x36000 sub-region status=PRINCE_FlashEraseWithChecker(&flashInstance,0x34000, 0x2000,kFLASH_ApiEraseKey); //Write 0x34000-0x36000 sub-region status=PRINCE_FlashProgramWithChecker(&flashInstance,0x34000, (uint8_t *)prince_iv_code,0x2000); Error Analysis According to UM11126（49.16.1 Functional details）, each crypto region has its own SKEY and IV code. SKEY and IV are used together by the PRINCE when encrypting or decrypting the data in the sub-regions of crypto region. For Instance, For PRINCE region1, each time after we execute erasing operation, new Skey1 and IV1 are generated, thus when executing erase/read/write operation to another sub-region, the old IV1 and new IV1 don’t match, which causes PRINCE can’t decrypt correctly.   Suggestion We suggest user using SR_ENABLE to set continuous crypto sub-regions. When erasing operation is needed, erasing all the crypto sub-regions together, avoid erasing part of the sub-regions. One sub-region size is 8K, make sure the erasing/writing address 8K aligned.   Thanks for the suggestion from johnwu‌

#emc‌ #读缓冲‌ #清洗‌

In newer version of LPC Boot ROM , checksum is added in location 7 ( offset 0x0000001C in vector table ) of Boot ROM. For some LPC device, for example LPC8N04, older Boot ROM version 0.12 (equipped in Rev B board) doesn’t contain checksum but newer version 0.14( equipped in Rev C board ) adds it. Boot ROM checksum is a criteria for valid user code. Bootloader can jump to user code only when detects checksum value correct. Otherwise, it stays at boot code.   Scenario: User may have this annoying problem: the program runs well if download code to LPC flash with debugger. However power off and on again, the code won’t run any more. If you also experience same in field, you may consider the possibility of Boot ROM checksum failed. This document tells how overcome this problem. 1. calculate checksum value by hand 2. calculate checksum value with Keil elfdwt.exe For detail, see attached article.

The LPC55S6x family was initial silicon die version was 0A, and this silicon was using on Revision A1 LPCXpresso55S69 boards. Revision 1B silicon has been used on Revision A2 boards. Both versions of silicon support the new, more robust debug session request method, but 1B silicon requires its use. If the correct version of IDE and/or debug probe drivers are not used then debug operation will be affected or non-functional.  When using Revision A2 boards, the current software release versions are required: MCUXpresso IDE Version  11.0.1 or later (11.1 or later recommended) [Note: IDE 11.0.1 may also be used but when using Revision A1 boards a hot fix is required for this release. See  MCUXpresso IDE v11.0.1 LPC55xx Debug Hotfix ] Note that you may need to start from a new workspace if transitioning from one developed using a Revision A1 board to a Revision A2 board (or any target system using Revision 1B silicon). IAR Embedded Workbench version 8.40.2 or later Keil uVISION LPC55S6x Device Family Pack (DFP) 12.0.1 or later SEGGER J-Link J-link version 6.54c or later should be used (from the SEGGER download site), and V6.64 or later is recommended. When using J-link with non-SEGGER IDEs (MCUXpresso, IAR, Keil), ensure that you IDE configuration is pointing to the latest J-Link drivers. If using MCUXpresso IDE 11.0.1 the included J-link drivers need to be updated to the latest version to support Revision A1 boards. See Updating a SEGGER J-Link installation on Windows for more information. For more information about silicon revision and tools, please refer to Understanding LPC55S6x Revisions and Tools  Please also note that there are Chinese versions of description regarding board revision, silicon revision and the corresponding tools as shown below: 中文版：LPC55S6x 版本更新及开发工具注意事项 中文版：LPC55S6x 0A和1B版本区别进阶

Description This is a demonstration-only design of a Point Of Sale (POS) system using the NXP LPC2214FBD144. Fiscal Cash Register (FCR) is a kind of POS machine which is popularized by governments, in particular, in China. A tax control function is added to the POS machine for revenue supervision. Considering the national standard and function expansion and complexity, an ARM MCU is used in the application market. The LPC2214 is the central control unit of the system. The system consists of an LCD, NAND flash, keypad, printer, RTC, IC card, etc. The FCR demonstration system is divided into two boards. The first is the NXP LPC22xx development board. On this board, general peripheral resources are integrated such as external flash and SRAM, keypad, ethernet, LCD, USB, CF card, and IDE. This can be considered as the motherboard used for the overall application. The FCR-specific resources such as NAND flash, UART, printer, and IC card are on the extended board. If more resources are needed, just replace the extended board. In the system, the LCD module is needed to display the operation and the keypad is used to send commands to the system. NAND flash is used to store the business data and the DOT Matrix printer is used to print the invoice. The IC card is used for security. The POS demo system demonstrates the functions which are important in a complete FCR system. The demo system can be used for software development and can help in reducing the development cycles and time to market. Block Diagram Products Below are recommended microcontrollers for use in implementing this design to a system. More Information Images Working Prototype Point of sale Schematics Example Codehttp://www.lpcware.com/sites/default/files/example.code__3.zip 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. schematics.zip 151.79 KB example.code_.zip 602.53 KB