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.

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

This article mainly introduces how to config CTIMER match 3 trigger ADC in LPC804, includes how to config related registers, and the code under SDK. Other LPC serials, also can refer to this DOC. 1.How To Configure ADC Part. 2.How to Configure CTIMER Part 3.Project Basic Information 4.Reference   Project is attached, it base on MCUXpresso IDE v11.1.1,  LPCXpresso804 board.  

#lpcopen.‌ #uart‌ #ring_buffer‌

#emc‌ #buffer‌ #flush‌

AN12037 is a commonly adopted solution among LPC users when USB DFU Secondary Bootloader. However when customers run the demo code, they would find their PCs has problem of recognizing LpcDevice. Scenario 1: “ LpcDevice flashes in Device Manager in a very short time then disappear for ever… “ Scenario 2: “ Device Manager can’t recognize LpcDevice…”     This is because the default demo code set DFU device only exist in 5 seconds. User must type dfu command ( dfu-util.exe -l ) very fast before de-initialize USB     So we suggest modify the code to increase the DFU device existence time. Change if ( dwSysTicks > 5 )‍ to if ( dwSysTicks > 30 )‍   Theoretically, the DFU existance time increases to 30 seconds. Thus we can have enough time slot to type DFU command.

How to start with SDK v.2.0 for LPC5411x using LPCXpresso IDE This document gives an overview of SDK v.2.0 for LPC5411x and also describes the steps required to build, run, and debug an example application provided in the SDK using LPCXpresso IDE. The steps described in the document are for the LPCXpresso54114 board (OM13089).   SDK for LPC5411x Derivatives Overview   The Software Development Kit (SDK) provides comprehensive software support for Microcontrollers. The SDK includes a flexible set of peripheral drivers designed to speed up and simplify development of embedded applications. Along with the peripheral drivers, the SDK provides an extensive and rich set of example applications covering everything from basic peripheral use case examples to full demo applications. The SDK also contains RTOS kernels and various other middleware to support rapid development on devices. SDK board support provides example applications for development and evaluation boards. Board support packages are found inside of the top level boards folder, and each supported board has its own folder (a SDK package can support multiple boards). Within each <board_name> folder there are various sub-folders to classify the type of examples they contain. These include (but are not limited to): demo_apps: Full-featured applications intended to highlight key functionality and use cases of the target MCU. These applications typically use multiple MCU peripherals and may leverage stacks and middleware. driver_examples: Simple applications intended to concisely illustrate how to use the SDK’s peripheral drivers for a single use case. These applications typically only use a single peripheral, but there are cases where multiple are used (for example, ADC conversion using DMA). rtos_examples: Basic FreeRTOS examples showcasing the use of various RTOS objects (semaphores, queues, and so on) and interfacing with the SDK’s RTOS drivers multicore_examples: Applications for both cores showing the usage of multicore software components and the interaction between cores.   Build, run and debug a SDK example   This section describes the steps required to configure LPCXpresso IDE to build, run, and debug an example application. The hello_world demo application targeted for the LPCXpresso54114 is used as an example, though these steps can be applied to any example application in the SDK.   1. Download and install the latest LPCXpresso version from the next link: http://www.nxp.com/products/software-and-tools/software-development-tools/software-tools/lpc-microcontroller-utilities/lpcxpresso-ide-v8.2.2:LPCXPRESSO 2. Follow the steps describe here to download the Software Development Kit (SDK) v2.0 for LPCXpresso54114: Generating a downloadable MCUXpresso SDK v.2 package  3. Select "File -> Import" from the LPCXpresso IDE menu. In the window that appears, expand the "General" folder and select "Existing Projects into Workspace". Then, click the "Next" button.       4. Click the "Browse" button next to the "Import from file:" option, and point to the example application project, which can be found using this path: <install_dir>/boards/<board_name>/<example_type>/<application_name>/lpcx/cm4 For this example, the specific location is: <install_dir_SDK_2.0_LPCXpresso54114>\boards\lpcxpresso54114\demo_apps\hello_world\lpcx\cm4 Then Click the "Finish" button. 5. There are two project configurations (build targets) supported for each SDK project: Debug – Compiler optimization is set to low, and debug information is generated for the executable. This target should be selected for development and debug. Release – Compiler optimization is set to high, and debug information is not generated. This target should be selected for final application deployment. So it is necessary to choose the appropriate build target. For this example, select the "Debug" target.   6. Build the project using the hammer icon. 7. Connect the development platform to your PC via USB cable between the Link2 USB connector (named Link for some boards) and the PC USB connector. If connecting for the first time, allow some seconds for the devices to enumerate.   8. In the Windows operating system environment, open the terminal application on the PC and connect to the debug serial port number. For this example it is used Tera Term.   Configure the terminal with these settings: 115200 No parity 8 data bits 1 stop bit    9. In LPCXpresso IDE, click on “Debug Configurations”. In the Debug Configurations dialog box, select the debug configuration that corresponds to the hardware platform you’re using. In this example, select is the CMSIS-DAP option under C/C++ (NXP Semiconductors) MCU Application. 10. After selecting the debugger interface, click the "Debug" button to launch the debugger. 11. Additional dialog windows may appear to select LPC-INK2 CMSIS-DAP emulator and core in case of multicore derivatives. Select it and click the "OK" button. Then select the Cortex-M4. The application is downloaded to the target and automatically run to main():    12. Start the application by clicking the "Resume" button. The hello_world application is now running and a banner is displayed on the terminal. Enjoy!!   Related links: Introducing MCUXpresso SDK v.2 for LPC54xxx Series  Generating a downloadable MCUXpresso SDK v.2 package  MCUXpresso Config Tools is now available!  

Demo demonstrate how to use EMC to connect with external SDRAM.

This content was originally contributed to lpcware.com by Jerry Durand When I found the M4 core in the LPC43xx series could be used as a hardware Floating Point Unit (FPU) while the actual code ran in the M0 core, I immediately thought of an application; a stand-alone 4-axis CNC control box for use with table-top milling machines.  Currently these machines are almost exclusively controlled by software running on very old PC hardware that has a parallel port and either MS-DOS or Windows XP for an operating system. Control of these milling machines entails tasks such as receiving g-code commands in ASCII text and a large amount of high-precision floating point operations which calls for an FPU.  This all has to occur rapidly and continously as each of the 4 motors has to be updated thousands of times per second. It seemed the M0 core would excel at the basic input/output (I/O) and timing functions while using the M4 as an FPU would speed the floating point operations. I originally hoped to port the entire RS274NGC open source Enhanced Machine Controller (EMC) software to the LPC4350 and run it with and without the FPU enabled, comparing the time to process a sample g-code file.  Problems getting the development software and examples set up caused me to run short of time even though NXP was fairly fast to fix problems as they were found.  Instead I modified one of the example programs (GPIO_LedBlinky) to enable testing the performance and this turned out to have some interesting results I might have otherwise missed. I ran the test code in eight different configurations:      1. FPU disabled, 32-bit float multiplication      2. FPU enabled, 32-bit float multiplication      3. FPUdisabled, 64-bit double multiplication      4. FPU enabled, 64-bit double multiplication      5. FPU disabled, 32-bit float division      6. FPU enabled, 32-bit float division      7. FPUdisabled, 64-bit double division      8. FPU enabled, 64-bit double division All tests were run from internal SRAM so external memory access time would not distort the results.  The optimization level was left at the default of zero (0) as I had problems with the compiler eliding parts of my code if I tried higher levels. Test results (loops per second averaged over 10 seconds):      1. 990,550        float, *      2. 2,768,000        FPU, float, *      3. 284,455        double, *      4. 276,796        FPU, double, *      5. 282,316        float, /      6. 1,894,000        FPU, float, /      7. 85,762        double, /      8. 85,053        FPU, double, / As expected 32-bit floating point operations run a lot faster with the FPU, 2.79 times faster for multiply and 6.7 times faster for division.  I would have expected somewhat better performance but this is still a significant improvement in speed. The 64-bit floating point operations were a different story, for both multiplication and division the operations ran SLOWER with the FPU than they do without it.  This points to an error in the library functions since it should be no worse than equal.  I was very surprised by this result and hope when the problem is fixed the 64-bit operations improve significantly. In conclusion the low cost of these parts and the simplicity of using the FPU allows performance improvement to an existing product that uses 32-bit floating point operations.  There is no long development cycle or fear of breaking something in your code as the changes to use the FPU consist of adding a small initilization routine for the FPU and enabling it in your compiler options.  This also leaves open the option of an even greater improvement with no hardware changes once you've had time to port your critical code to run directly on the M4 core instead of just using it as an FPU. In the case of 64-bit floating point operations, it seems this may not be the best choice if you only use the M4 as an FPU.  Running your critical code directly on the M4 may give a significant improvement but that requires porting the code to run on both cores and isn't something I tested.

Abstract This paper discusses our approach to crypto acceleration and asset protection using novel techniques that help bring high levels of security to low-cost microcontrollers with minimal power and area penalty. CASPER, our asymmetric cryptography acceleration engine, aims to optimize crypto algorithm execution (e.g., RSA, ECC). It is built on a hardware-software partitioning scheme where software functions map asymmetric crypto functions to the hardware modules of the accelerator, delivering sufficient flexibility to software routines to enable mapping of new algorithms. Further efficiency is achieved by making use of the co-processor interface on the Arm® Cortex®-M33 core. Important assets such as keys, proprietary and/or licensed application software are protected against side-channel analysis or cloning using SRAM PUF and PRINCE. SRAM PUF technology enables secure storage of root-of-trust keys and user keys by exploiting the deep sub-micron process technology variations. PRINCE is a low-latency lightweight cryptography algorithm implementation in hardware that allows encrypted non-volatile storage and real-time, latency-free decryption of the execution code. Read More >

        In recently, NXP released a new sub-series: LPC80x which contains two kinds: LPC802 and LPC804 now, they have a variety of package types for choose and the LPC804 seems like the advanced version to LPC802. For details, please refer to these two articles: 《小巧‘零’珑的MCU：LPC80X面面观》 《LPC800系列选型指南》        Below are block diagrams of LPC802 and LPC804. We can find the difference easily after comparing them. Fig1 LPC802 system block diagram Fig2 LPC804 system block diagram        According to the above two figures, we can find that LPC804 has the capacitive touch interface, programmable logic unit (PLU), 10-bit DAC output, and an I2C interface. But these peripherals are not supported in the LPC802. In further, LPC804 has two times as much memory as LPC802 does.Especially, the capacitive touch interface provides hardware support for LPC804 to design the complex HMI implemented.        In the coming section, I'd like to illustrate the problem capacitive touch demo and share some experience to overcome it. Capacitive Touch Demo Testing 1. Evaluation board (OM40001) Fig3 LPCXpresso804 Develpment Kit        2. Demo code        CapTouch_5ch demo is from Code Bundle (supports Keil, IAR, and MCUXpresso), after reset, all the 5 LEDs would be On and Off one by one and flash together. Please do not touch the pads during this period. After all the LEDs are silent, touch any pad and the responding LED will be on until your finger moves away. Meanwhile, run the Freemaster project to monitor the sensing value in runtime. Fig4 Capacitive Touch Shield Fig5 FreeMASTER monitor the sensing value          3. Testing summary         In general, the testing result is not very good, for instance, when touching S4 and S3, LED D1~D5 may be lighted arbitrarily, even the S1 and S2 which have the best performance,  the responding LED usually be on when touching them, sometimes other LEDs would response the touching event.         Combining with the observation of FreeMaster, it can get the conclusion that the discrimination of these touchpads is not enough to distinguish each other.          4. Workaroud         According to the feedback from the AE co-worker, the discrimination performance of the touchpad is mainly determined by the PCB design and the power supply source. Obviously, the touchpad is impossible to be modified, so we should consider eliminating the power supply's noise to improve the performance.          I tried these three power source for supply. Using the USB port of the notebook, meanwhile, the notebook is supplied by 220 V, 50 Hz Using the USB port of the notebook Using mobile power       After several rounds of testing, it illustrates that demo code can work well when using mobile power to supply, as the mobile power is clean enough and the noise is the smallest.       Note: Slowing the FCLK can extend the scan period for a channel (more energy is released through YL for each recharge cycle), then increase the discriminability performance.  mobile power supply

The MCUXpresso IDE SWO trace function is a special feature which enables user to observe variable update, interrupt entry/exit timing, interrupt event statistic, to print information in SWO ITM Console while the MCU is running. The MCUXpresso IDE SWO trace function is a supplement to the debugger of the MCUXpresso IDE. The main advantage is to display variable, print information, list interrupt entrying/exitting/returing while the MCU is running.  The documentation describes the hardware connection to implement the SWO function, MCUXpresso configuration and source code to implement the function. 

This content was originally contributed to lpcware.com by George Romaniuk     This project included testing the performance of the SPIFI interface on LPC4350. Example files were modified to run the M4 core at 200MHz and read and write to SPIFI attached FLASH. Timer was added to measure the execution and data transfer time. Reads were at an amazing 44.9MByte/s; writes were much slower due to FLASH. In addition to SPIFI, some DSP routines were timed and performance was documented.

This document introduces how to debug TrustZone project on MCUXpresso IDE.   Use the latest version of MCUXpresso IDE v10.3.1. Project is from SDK_2.5.0_LPCXpresso55S69. Board is LPCXpresso55s69, use the LinkServer debug probe(on board debugger).   Every TrustZone based application consists of two independent parts - secure part/project and non-secure part/project. The secure project is stored in SDK_2.5.0_LPCXpresso55S69\boards\lpcxpresso55s69\trustzone_examples\<application_name>\ cm33_core0 \<application_name>_s directory. The non-secure project is stored in SDK_2.5.0_LPCXpresso55S69\boards\lpcxpresso55s69\ trustzone_examples\<application_name>\ cm33_core0 \<application_name>_ns directory. The secure projects always contains TrustZone configuration and it is executed after device RESET. The secure project usually ends by jump to non-secure application/project. In this document, we use “hello_world” as example, this project contains both “hello_world_s” and “hello_world_ns” projects. Unlike Keil or IAR IDE, MCUXpresso IDE can’t debug jump directly from secure project to no-secure project, so we need add the no-secure executable file to secure project debug configuration manually(For this version of MCUXpresso IDE v10.3.1, we need do this step, while for  the later new versions, maybe they support jump directly from secure project to no-secure project ). Steps outline: Import “hello_world_s” and “hello_world_ns” project. Build “hello_world_s” and “hello_world_ns”, without any error. Erase flash. Program no-secure project “hello_world_ns ”. Kill active debug. Add the location of file “lpcxpresso55s69_hello_world_ns.axf” to Debugger commands of “hello_world_s” project, and download “hello_world_s” project. After finish download, it stop at “hello_world_s” project, set a breakpoint at “hello_world_ns” project: Debug project Detailed steps please refer to DOC in attachment. Hope it helps, BR Alice

This document is an introduction to the Programmable Logic Unit (PLU) provided for the LPC804 MCU device. PLU is used to create small combinatorial and/or sequential logic networks including simple state machines. This allows to replace external components like the 74xx series, which are used for the glue logic with the microcontroller and external devices, making simple the PCB and saving design costs. Figure 1. LPC80x MCU families The PLU is comprised of an array of 26 inter-connectable, 5-input Look-up Table (LUT) elements, and 4 flip-flops.  Each LUT element contains a 32-bit truth table (look-up table) register and a 32:1 multiplexer. During operation, the five LUT inputs control the select lines of the multiplexer. This structure allows any desired logical combination of the five LUT inputs. Figure 2. PLU Features The PLU is used to create small combinatorial and/or sequential logic networks including simple state machines. The PLU is comprised of an array of 26 inter-connectable, 5-input Look-up Table (LUT) elements, and 4 flip-flops. Eight primary outputs can be selected using a multiplexer from among all of the LUT outputs and the 4 flip-flops. An external clock to drive the 4 flip-flops must be applied to the PLU_CLKIN pin if a sequential network is implemented. Programmable logic can be used to drive on-chip inputs/triggers through external pin-to-pin connections. A tool suite is provided to facilitate programming of the PLU to implement the logic network described in a Verilog RTL design.   Advantages Some advantages of the PLU are: Replace the combinational logic of the 7400 series. State machine design using Flip-flop. Address decoder. Pattern match. Low-power application. PLU works in deep-sleep and power-down mode. Programmable so PLU can be reprogrammed and reused. Seamless connection using SWM and PLU. Pin description There are up to six primary inputs into the PLU module, one clock input, and eight primary outputs. All the inputs are connected directly to the package pins via chip-level I/O multiplexing.  All these pins can be enabled by configuring the relevant SWM register (PINASSIGN_FIXED0). A particular logic network may not require all of the available inputs or outputs. The user can specify which inputs and outputs to use, and which package pins those inputs and outputs will connect to as part of the overall top-level IO configuration. Registers Programming the PLU to implement a particular logic network involves writing to the various Truth Table registers to specify the logic functions to be performed by each of the LUT elements, programming the Input multiplexer registers to select the five inputs presented to each LUT, and programming the Output multiplexer register to select the eight primary outputs from the PLU module. Programming of all of these registers is performed only during initialization. Table 1. PLU registers PLU Shield board with LPCXpresso804 The OM40001 package includes a shield board for use with the LPCXpresso804 board when prototyping programmable logic unit (PLU) designs. The PLU shield provides the following features to assist with this type of development: 5 slide switches to enable 5 possible PLU inputs to be connected to VDD (marked as VCC on the Shield) or GND through a resistor (to set those inputs to a logic 1 or zero). 8 LEDs with jumpers to connect/disconnect possible PLU outputs for visual status indication. Push button option for momentary / edge signal inputs. Low-frequency oscillator with 1024Hz and 8Hz outputs. The PLU shield also includes a test circuit that can be used to implement a simple continuity tester. Several signals from the LPC804 used on the PLU Shield are shared with other functions on the main LPCXpresso804 board. Please review jumper settings on the LPCXpresso804 board carefully before installing the PLU Shield. https://www.nxp.com/docs/en/user-guide/UM11083.pdf  Figure 3. LPCXpresso804 + PLU Shield = PLU demo board   PLU input options On/off switches S1 through S5 connect possible PLU inputs to VDD or GND via a resistor, enabling those inputs to be driven to a known, fixed state. PIO0_8 is connected to a push button (S6) and a 100kohm pull up to VDD; PIO0_8 will be grounded when the button is pressed. Table below shows these connections. Table 2. PLU input on/off switches. A digital oscillator circuit is also included on the Shield, with 1.024kHz and 8Hz outputs available. LPC804 signal PIO0_1 can be connected to these oscillator signals in order to provide a low-speed clock to the flip-flops in the PLU block. The center pin (2) of JP12 connects to PIO0_1, so a jumper can be placed onto JP12 to connect this signal to the required clock (see markings on the Shield silk screen.) An external clock can be provided to the PLU by connecting it to the center pin of JP12. PLU output options LEDs are used to monitor the PLU outputs. Due to the limited number of pins on the chip/board, some of the inputs and outputs are shared. Table 3. PLU shield LEDs. PLU examples You have two options to find a PLU example: Using the SDK for the LPCXpresso804. You can download the SDK for the LPCXpresso804 from Welcome | MCUXpresso SDK Builder The PLU project is a simple demonstration program of the SDK PLU driver. In this example, a number of switches are used act as PLU inputs and LEDs are used to monitor the PLU outputs to demonstrate the configuration and use of the Programmable Logic Unit (PLU). Using the LPC804 Example Code Bundle. Code Bundle, containing source code for drivers, example code and project files. You can download it from LPCXpresso804 board for LPC804 Microcontroller (MCU)|NXP  It is recommended to use the PLU configuration tool. Please check the following links for more details. PLU Tool Direct, LUT-based design: https://www.nxp.com/video/part-2-plu-tool-direct-lut-based-design:Part2-PLU-config-tool-verilog PLU Tool Schematic design: https://www.nxp.com/video/part-3-plu-tool-schematic-design:Part3-PLU-config-tool-schematic PLU Tool Importing Verilog files: https://www.nxp.com/video/part-4-plu-tool-importing-verilog-files:Part4-PLU-config-tool-directlut