I already have several customers met SB file loading error Inject command 'receive-sb-file' while working on LPC55S6xx 1B version. There is significant change of Secure Boot in LPC55S6xx 1B version and 0A version. To solve this problem, we need to understand it first.     1  SB2.1  vs. SB2.0 SB2 container is described in elftosb User’s Guide. SB file config file contains configuration commands that will be processed after SB2 file is loaded in the device. The image location is stated in the "sources" .bd file section. SB key in text file is used for encryption with elftosb command line tool.   The 0A version of the LPC55S6xx silicon supports version 2.0 of the SB image format. The 1B version of the LPC55S6xx silicon supports version 2.1 of the SB image format. The main difference between version 2.0 and version 2.1 is in the usage of the digital signature. SB 2.0 is encrypted and SB2.1 is encrypted + signed.     2. SB file Preparation and Usage   Example of use (Encrypted SB2):   elftosb -f lpc55xx -k "sbkek.txt" -c "commandFile.bd" -o "output.sb2" "input.bin"   where -f = family lpc55xx -k = path to KEK file (SBKEK) -c = path to command file to be processed:   options { flags = 0x4; // 0x8 encrypted + signed, 0x4 encrypted buildNumber = 0x1; productVersion = "1.00.00"; componentVersion = "1.00.00"; } sources { inputFile = extern(0); } section (0) {       erase 0x0..0x40000; load inputFile > 0x0; }   -o = path to output file   files... = path to files (usually image files), which will be replacing placeholders defined in command file, paths can be hardcoded in command file and then not inserted as input   Example of use (Encrypted + Signed SB):   1 root key   elftosb.exe -f lpc55xx -k "sbkek.txt" -c "commandFile.bd" -o "output.sb2" -s "selfsign_privatekey_rsa2048.pem" -S "selfsign_v3.der.crt" -R "selfsign_v3.der.crt" -h "RKTH.bin" "input.bin"   4 root keys   elftosb.exe  -f lpc55xx -k "sbkek.txt" -c "commandFile.bd" -o "output.sb2" -s private_key_1_2048.pem -S certificate_1_2048.der.crt -R certificate_1_2048.der.crt -R certificate_2_2048.der.crt -R certificate_3_2048.der.crt -R certificate_4_2048.der.crt -h "RHKT.bin" "input.bin"   where -f = family lpc55xx -k = path to KEK file (SBKEK) c = path to command file to be processed   options { flags = 0x8; // 0x8 encrypted + signed, 0x4 encrypted buildNumber = 0x1; productVersion = "1.00.00"; componentVersion = "1.00.00"; } sources { inputFile = extern(0); } section (0) {       erase 0x0..0x40000; load inputFile > 0x0; }   -o = path to output file -s = path to private key of certificate used for signing -S = path(s) to certificates in certificate chain, each certificate in chain must be specified with new -S switch in order of how was chain created (root certificate first) -R = path(s) to root certificate(s), 1-4 root certificates can be specified, each root certificate must be specified with new -R switch, one of the root certificates must be first certificate specified by -S switch -h = path and name of output binary file generated by elftosb, which contain hash of hashes of all root certificates (RKTH), which must be uploaded to the device register files... = path to files (usually image files), which will be replacing placeholders defined in command file, paths can be hardcoded in command file and then not inserted as input The SB2.0 file created with the updated binary image can be loaded into the device through ISP command handler with command “receive-sb-file“   blhost -p COMxx receive-sb-file <path to the secured binary(.sb2)>   The SB2.1 file created with the updated binary image can be loaded into the device through ISP command handler with command “receive-sb-file“ but keep in mind that before sending SB2.1 file into device has to be there already RKTH in CMPA (see AN12283 chapter 5.5 CMPA preparation) and enabled RoT keys in ROTKH_REVOKE field at CFPA page address 0x9DE18 (see chapter AN12283 5.4 CFPA preparation).   blhost -p COMxx receive-sb-file <path to the secured binary(.sb2)>   After successfully loading the SB2 file it is executed as configured in SB configuration file (.bd file). The above figure shows an example of SB configuration file. When the file is executed, the internal flash address from 0x0 to 0x40000 is erased. After flash erase operation, the image mentioned in the sources parameter is loaded to address 0x0. Reset the device after these operations. The updated image loaded into internal flash starts to execute.    English and Chinese versions of this article are both attached.

Introducing MCUXpresso SDK v.2 for LPC54xxx Series What's New in MCUXpresso SDK v.2 for LPC54xxx? The Software Development Kit (SDK) 2.0.0 is a collection of software enablement for microcontrollers that includes peripheral drivers, multicore support, and integrated RTOS support for FreeRTOS OS and μC/OS. In addition to the base enablement, the SDK is augmented with demo applications and driver example projects, and API documentation to help the customers quickly leverage the support of the SDK. Development Tools The MCUXpresso SDK v.2 for LPC54xxx 2.0.0 was compiled and tested with these development tools: - LPCXpresso 8.2.0 - IAR Embedded Workbench for ARM® platform version 7.60.2 - MDK-ARM Microcontroller Development Kit (Keil)® 5.20 Supported Development Systems Development boards MCU devices LPCXpresso54114 LPC54114J256BD64, LPC54114J256UK49, LPC54113J128BD64, LPC54113J256BD64, LPC54113J256UK49 LPCXpresso54608 LPC54605J256ET180, LPC54605J512ET180, LPC54606J256ET180, LPC54606J512BD208, LPC54607J256ET180, LPC54607J512ET180, LPC54607J256BD208, LPC54608J512ET180, LPC54608J512BD208   SDK Board Support Folders 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.   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 usb_examples: Applications that use the USB host/device/OTG stack. multicore_examples: Applications for both cores showing the usage of multicore software components and the interaction between cores. Example Application Structure This section describes how the various types of example applications interact with the other components in the SDK. To get a comprehensive understanding of all SDK components and folder structure, see the SDK v.2.0 API Reference Manual document (SDK20APIRM). Each <board_name> folder in the boards directory contains a comprehensive set of examples that are relevant to that specific piece of hardware. We’ll discuss the hello_world example (part of the demo_apps folder), but the same general rules apply to any type of example in the <board_name> folder. In the hello_world application folder you see this: All files in the application folder are specific to that example, so it’s very easy to copy-paste an existing example to start developing a custom application based on a project provided in the SDK. Related links: For information on how to import and debug the MCUXpresso SDK example projects using LPCXpresso or generate your MCUXpresso SDK package take a look to this document: How to start with SDK v.2.0 for LPC5411x using LPCXpresso IDE Generating a downloadable MCUXpresso SDK v.2 package https://community.nxp.com/docs/DOC-333369  MCUXpresso Config Tools is now available!  

Contents 1. Principle of energy measurement 2. Energy measurement test   2.1 Use in non-Debug state   2.2 Use in Debug state   During the operation of MCU, real-time measurement of board current and voltage is of great significance to the stability of system power consumption. Especially in scenarios that are sensitive to voltage and current fluctuations, it is particularly important to collect and analyze high-frequency samples. MCUXpresso IDE integrates the power measurement function, which can measure the current and voltage of the development board in real time and calculate the real-time power consumption. Based on MCUXpresso IDE v11.5.0, this article mainly explains power measurement function usage. 1.   Principle of energy measurement Currently the MCUXpresso IDE energy measurement function supports the following development boards: -LPCXpresso546x8/540xx/54S0xx -LPCXpresso54102 -LPCXpresso51U68/54114 -QN9090-DK006/ JN5189-DK006/IOTZKB-DK006 -QN9080DK The power measurement actually uses the LPC-Link2/MCU-Link debugger on the development board to collect the conversion value of the A/D conversion chip, and perform software calculation to obtain the power measurement result. Taking LPCXpresso54628 development board as an example, the following is the circuit diagram of the power measurement part: Fig.1 The MAX9634TEUK+T is a precision current amplifier. And ADC122S021 is a 12-bit A/D converter with dual-channel sampling, its rate can reach 200ksps. ADC122S021 collects LPC54xx_CURR and SHLD_CURR voltages, IDE sets Target resistor (Total Rvsense in the figure) and Shield resistor (resistance value corresponding to SHLD_CURR) in advance. The LPC-Link2 debugger can calculate the voltage, current and power consumption information by collecting AD conversion values. 2.   Energy measurement test Taking LPCXpresso54628 development board as an example. Open the menu bar : Analysis->Energy Measurement. The Energy Measurement interface will appear in the lower right corner of the screen, which is divided into Plot drawing and Config configuration interface. It can be used in Debug state or in non-Debug state during measurement. Test the case of LED small light flickering and observe the changes of voltage, current and energy consumption. Note that the LPC-Link2 debugger version should be CMSIS-DAP probe version 5.147 and above. 2.1 Use in non-Debug state Click the button  in energy measurement interface and select the measured in the config interface. You can select the target voltage, target current and shielding current. The sampling rate can be selected as 50ksps, 62.5ksps or 100ksps. First select the model of the development board to be tested, and then continue to select the target resistance and shielding resistance. The target resistance value is selected according to the jumper cap description in Figure 1. The resistance value of the shielding resistance is the fixed resistance value of development board. As shown in the figure below: Fig.2 Select the target voltage to be measured, and click the button to run the Energy Measurement interface. You can see the slight fluctuation of voltage in the plot interface and view the average voltage through the delimited area of horizontal measurement, as follows: Fig.3 Select the target current to be measured. Before measuring the target current, click Read from target on the config interface to calculate the average value of the target voltage within 0.5s for subsequent power consumption calculation. Click the run button to see that the target current fluctuates slightly with the flashing of the small light in the plot interface. At the same time, check the average current, power consumption and energy consumption through the delimited area of horizontal measurement, as follows: Fig.4 2.2 Use in Debug state When used in the debug state, you can use MCUXpresso IDE or KEIL to enter the debugging state. Click the button on the energy measurement interface to read the power consumption in the debug state. The measurement process is the same as the non-Debug state, as follows: Fig.5 This is a general enablement document of how to use energy measurement feature in debug and non-debug mode. For more, please refer  MCUXpresso_IDE_Energy_Measurement. pdf under MCUXpresso IDE install folder.    

This article mainly introduces how to re-enable SWD after disabled. 1.Problem description The Enhanced Code Read Protection (ECRP) of the LPC546xx series is used to configure different security levels for user programs. It is configured when the startup image file offset is 0x20 and is used in combination with OTP. Users of LPC546xx can disable SWD and ISP by configuring ECRP values. Some users need to re-enable SWD after disabling SWD, you can use the J-link commander "unlock LPC5460x" command or re-enable SWD based on LPC-LINK2 CMSIS-DAP these two methods, this article will introduce the two methods in detail. 2.Theoretical analysis and solutions Customer’s example: LPC54605:Configure ECRP to 0x00015800. After disabling SWD, it needs to be restored. When the ECRP value is 0x00015800, we analyze from high to low through  user manual. In ECRP, 31:18 bits are reserved, and 17:16 bits determine the status of SWD. In this example, 17:16=01 ,this means that SWD is disabled.   15: 14 =01, it is not allowed to enter ISP through IAP call.   13: 12 = 01, it is not allowed to enter ISP through pin.   11: 10 = 10, IAP sector erase / write protection is disabled, so sector protect (5:0) is ignored.   At this point,  SWD (17:16) is DISABLED, ISP Entry from ISP (15:14) is DISABLED, and ISP Entry from Bootloader (13:12) is DISABLED, the IAP Mass Erase can still be used to erase the entire Flash to recover a device. as long as the OTP MASS ERASE is ENABLED. If the OTP has been configured and bit 4 is set to 1, that is, disabled mass erase command, the SWD can never be recovered again. When Mass Erase is enabled, the Debug Mailbox is also enabled and allows a debugger to communicate with the bootloader to execute a Mass Erase.   Therefore, the Debug Mailbox can be used to perform Mass Erase operation and restore ECRP settings. To achieve the purpose of re-enabling SWD. 3. Re-enable SWD 3.1 Use "unlock LPC5460x" command re-enable SWD If use J-link debug probe, use "unlock LPC5460x" command to re-enable SWD. Open the J-Link commander and enter unlock to view supported devices. Enter the corresponding chip command. In this paper, the command is unlock LPC5460x. As shown in the picture below:   However, for some chips, this method still fails to re-enable SWD. The following is a method of SWD recovery based on LPC-LINK2 CMSIS DAP. If the unlock LPC546xx command does not work, use the following method. 3.2 LPC-LINK2 CMSIS-DAP re-enable SWD If use CMSIS-DAP debug probe, use below steps to re-enable SWD. IDE: MCUXpresso IDE v11.7.1_9221 or other version. IDE installation path: C:\nxp\ MCUXpresso IDE v11.7.1_9221. The development board emulator firmware uses LPC-LINK2 CMSIS-DAP. Tool script: LPC546xxMassErase.scp. Tool script path: C:\nxp\ MCUXpresso IDE v11.7.1_9221 \ide\binaries\Scripts. The operations are the same for other versions of MCUXpressoIDE and other installation paths. 1) Put LPC546xxMassErase.scp script in the path: C:\nxp\MCUXpressoIDE_11.7.1_922\ide\binaries\Scripts 2) Open a command prompt window. 3) Change the path to C:\nxp\ MCUXpresso IDE v11.7.1_9221 \ide\binaries.   4) Run the redlinkserv -commandline command. 5) After running the redlinkserv -commandline command, you should see the redlink> prompt.   6) Run the load command "C:\nxp\MCUXpressoIDE_11.7.1_9221\ide\binaries\Scripts\LPC546xxMassErase.scp". 7) After executing the load command, you should see that "LPC546xxMassErase.scp" is being loaded. 😎 Execute the run command. 9) After executing the run command, you should see the following message.   In this case, the SWD interface can be used normally. 4.Query ECRP level In the LPC546xx user manual, we can see  ISP-AP command, one function is query the ECRP  level, that is, to view the ECRP configuration of this chip.   From the log in part 3, we can see the returned ECRP level:   However, there is no explanation in the user manual, so here we show the meanings of each bit. There is a table translation from the ECRP level user defined and the ECRP definition used by the ROM code: /* Feature bit defines */ #define CRP_JTAG_EN_BIT         (1 << 6) #define CRP_MASS_ERASE_DIS_BIT  (1 << 7) #define CRP_IAP_PROT_EN_BIT     (1 << 😎 #define CRP_ISP_PINS_EN_BIT     (1 << 9) #define CRP_ISP_IAP_EN_BIT      (1 << 10) #define CRP_DBG_MBOX_EN_BIT     (1 << 11) #define CRP_COUNT_MASK          0x3F #define CRP_DEFAULT_FEATURES    0xFFFFFFFF #define CRP_MASS_ERASE_ONLY     (CRP_SECT_ERASE_DIS_BIT) For example: In CRP_JTAG_EN_BIT, 1 is JTAG/SWD enabled and 0 is disabled. It’s corresponding to ECRP value bit 17 and 16. In CRP_MASS_ERASE_DIS_BIT, 0 is Mass Erase allowed and 1 is disallowed. It’s corresponding to the combination of ECRP value bit 0~5, bit 10~11, and bit 14~15. In CRP_IAP_PROT_EN_BIT, 1 is IAP protection enabled and 0 is disabled. It’s corresponding to ECRP value bit 14~15. In CRP_ISP_PINS_EN_BIT, 1 is ISP pin enabled and 0 is disabled. It’s corresponding to ECRP value bit 12~13. In CRP_ISP_IAP_EN_BIT, 1 is ISP in IAP mode enabled and 0 is disabled. It’s corresponding to ECRP value bit 14~15. In CRP_DBG_MBOX_EN_BIT, 1 is ISP-AP or debugger mailbox enabled and 0 is disabled. It’s corresponding the combination of some reserved ECRP bits and OTP setting. Of course, all these ECRP value used by the ROM not only look into the user defined ECRP value but also check the OTP setting. When “Query ECRP Level” is called, it returns the value used by the ROM code, but not the ECRP value programmed in the image by the user. 5.Summary: In the LPC546xx series, even if SWD is disabled, the debugger can communicate with LPC5460x through the Debug mailbox. As long as OTP does not disable Mass Erase, the debugger can ask LPC5460x to perform mass erase through the Debug Mailbox to re-enable SWD functionality. In addition, the article also adds the specific meaning of the value returned by the ISP-AP command.    

1. General Jointly developed by NXP and Embedded Artists, the MCU-Link Pro is a fully featured debug probe that can be used with MCUXpresso IDE and 3rd party IDEs that support CMSIS-DAP and/or J-Link protocols. MCU-Link Pro is based on NXP’s MCU-Link architecture, found in the MCU-Link low cost debug probe and on board evaluation boards, and runs the same firmware as all these implementations. In addition to SWD debug, SWO profiling and a USB to UART bridge features (VCOM) found in the base MCU-Link, the Pro model adds a J-Link LITE firmware option, energy measurement, analog signal monitor, USB to SPI and I2C bridging capability and an on-board LPC804 for peripheral emulation. MCU-Link Pro is based on the dual Arm® Cortex-M33® core LPC55S69 microcontroller, and features a high speed USB interface, providing high performance debug at low cost. The USB bridging feature is supported by the free LIBUSBSIO host library from NXP. MCU-Link Pro is compatible with Windows 10, MacOS and Linux. The product comes with the necessary firmware installed, with free utilities provided to enable future firmware updates from NXP to be installed. MCU-Link Pro kit provides all parts that need to be used. Kit Contains MCU-Link Pro debug probe 10 pin to 10 pin Cortex debug cable 10 pin to 20 pin Cortex debug cable Digital port / analog input adapter cable Spare jumpers 2. MCU-Link Pro Overview MCU-Link Pro has complete functions. This article mainly introduces the usage and precautions of several basic functions, including SWD debugging, UART (VCOM) and energy measurement. The following figure is the reference diagram of MCU Link Pro, covering all functions, and the highlighted part is the function used in this article.   2.1 SWD debug As a debugger, the most basic function of MCU Link Pro is debugging, and now commonly used is SWD debug. When you get the development board, you can see that there are three SWD interfaces on it. Only J7 is the SWD interface to debug target board. It is on the opposite side of the USB interface to facilitate the connection and debugging of the target board. The other two interfaces J3 and J11 are SWD interfaces of LPC55s69 and LPC804 respectively. Another important function of this debugger is that it can supply power to the target board. The use method is to connect J6 with jumper, and 1.8V and 3.3V power supply can be selected through J5. The specific connection is shown in the figure below: - Connect the SWD interface of J7 and target board with debug line. - J6 connecting jumper cap (supplying power to target board).  The USB cable connects J1 and the computer, so you can debug with MCUXpresso IDE or other IDEs. CMSIS-DAP and J-Link debugging protocols are supported. For how to update the debugger firmware, please refer to:https://www.nxp.com/document/guide/getting-started-with-the-mcu-link-pro:GS-MCU-LINK-PRO   2.2 UART (VCOM) Usage In the development and debug stage, users often need to print information through the serial port. Using MCU Link Pro, without additional hardware, directly connect the TX and Rx of target UART with the Rx / TX of UART of MCU Link Pro. Through the VCOM function, you can print information from the USB port to the serial port assistant at the PC end. The specific connection is shown in the figure below: - J19-8 (purple line) connects UART TX of target board - J19-9 (gray line) connects the UART RX of the target board - J19-1 (GND) connect GND of target board - J14 disconnected - J6 plug in the jumper cap (supply power to the target board)   2.3 Energy measurement The MCU Link Pro board contains a circuit that can measure the current or voltage of the target board, and it can be calibrated automatically every time it is powered on without manual intervention. There are two maximum measurement ranges for energy measurement. If the data is higher than the maximum range, the measurement result is inaccurate. The two maximum measurement ranges are as follows, which need to be configured with J16, J17 and J18.   Energy measurement needs to be used with MCUXpresso IDE, and the results are displayed in the IDE interface. Use J9 port on the board. The specific connection is shown in the figure below: - J9-1 connects the power supply end of the target board. - J9-3 connects the chip ends of the target board. - J9-2 connects the GND of the target board For details on how to use the MCU Xpress IDE interface, please refer to：<MCUXpresso_IDE_Energy_Measurement.pdf> 3. Test result The test results are as follows:          

Recently I found some customers have a bit of problem when porting project from one MCU to another, so this article using simple steps demonstrates how to change MCU with MCUXpresso. There is also a video demonstrated the detail steps in attachment. Pay attention, as MCUXpresso User Guide says: All projects are associated with a particular MCU at creation time. The target MCU determines the project memory layout, startup code, LinkServer flash driver, libraries, supporting sources,launch configuration options etc. etc. so changing a project’s associated MCU should not be undertaken unless you have a total grasp of the consequence of this change. Therefore rather than changing a project’s associated MCU, it is strongly recommended that instead a new project is generated for the desired MCU and this new project is edited as required. However, on occasion it may be expedient to reset a project’s MCU (and associated SDK) and this can be achieved as follows. For example, changing lpc55s69 to lpc55s06, we need install SDKs for lpc55s69 and lpc55s06 before all the below steps. 1 - Change MCU & Package 1.1 – Change MCU Right click “MCU” under Project tree, choose “Edit MCU” Uncheck ”Preserve memory configuration”(it is checked by default)->choose LPC55S06->there is a warning, choose Yes. We can see the Memory details changed to lpc55s06, then click ”Apply and close”. 1.2 – Change Package 2 - Change Compiler Definitions In Properties view->Settings->MCU Compiler ->Preprocessor, change the definition for CPU from LPC55S69JBD100 to LPC55S06JBD64 as below: 3 – Change/add SDK driver for LPC55s06 Selected project, then click ”Manage SDK components”, choose the drivers our application used, for example, clock, power, usart. Click “OK”, then click “Yes” to update. Delete LPC55S69 device related files: Add “system_LPC55S06.c” and “system_LPC55S06.h” files: 4 - Change startup file. Delete LPC55s69 startup files, add “startup_lpc55s06.c”, we can find the startup file in any SDK demo. 5 - Change board related files. Refer to our own new board, change files under “board” folder, for example pins, uart number, here directly copy from SDK demo for LPCxpresso55s06 board. 6 - Test the project  function with new board Build project until no compile error, download and run it, result as below.        

Unboxing of the Mini-Monkey.    This was a demonstration of how you can use a low cost 2-layer PCB process with the LP55S69 in the 0.5mm pitch VFBGA98 package.    We used Macrofab for the prototypes and the results were fabulous. Blog articles on the Mini-Monkey: https://community.nxp.com/community/general-purpose-mcus/lpc/blog/2020/03/13/mini-monkey-part-1-how-to-design-with-the-lpc55s69-in-the-vfbga98-package https://community.nxp.com/community/general-purpose-mcus/lpc/blog/2020/03/29/mini-monkey-part-2-using-mcuxpresso-to-accelerate-the-pcb-design-process https://community.nxp.com/community/general-purpose-mcus/lpc/blog/2020/04/19/lpc55s69-mini-monkey-build-update-off-to-fabrication

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!

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

        In recent years of MCU technology evolving, booting from the external flash seems to become more and more popular, actually, LPC already has employed this technology for many years.         NXP's recently released the LPC540xx family which continues the trend of high-performance flash-less MCU.         The developers may be a bit confused with the external FLASH which is used for storing the program, as they are used to directly using the internal FLASH for programming and debugging the chip. But, don't worry, let me introduce it in the following sections. LPC54018's three ways of loading program        In general, RAM stores data, however, RAM can also store programs. In previous projects, we occasionally move some key functions in RAM in order to improve the execution speed of these programs. The current implementation is to put all the programs in RAM more thoroughly. Based on this idea, you can directly use the debugger to load the executable image into the on-chip RAM and this method is called RAM TARGET.       After downloading the executable program image file to the external flash, when the bootloader loads the complete image to on-chip RAM to run, the method is called the Plain Load Image method.             Actually, both of these above ideas are routine, chip designers have also created a "super-capability" that allows the chip to directly execute external FLASH programs (Execute In Place, XIP). With this 'superpower', no matter whether the program boot from the external FLASH or the internal FLASH, there is no difference in operating performance.       The RAM TARGET method mentioned above is only suitable for debugging the application. Once the chip is powered off or reset, the downloaded program in the RAM will disappear. Meanwhile, the size of the RAM also give some restrictions for debugging.        In the Plain Load and XIP modes, the executable image file is stored in the external flash. After MCU is powered, the bootloader which is resided in ROM copies the first 512 bytes from the image (vector components and image header) into internal SRAMX at location 0x0000 0000 to validate the vector table and image header to confirm the booting mode. And the program will not be lost after power-off or reset. Fig1 illustrates the boot process of LPC54018. Fig1 LPC54018 boot process flow Experiment show         Board: LPCXpresso54018 board (OM40003) Fig1 LPCXpresso54018 board       Demo code: Hello world (From the SDK), modifying the hello world code in below way, which points out the load program way and date time. PRINTF("hello world. XXXXXXXX \r\n");    PRINTF("hello world, %s, %s.\r\n", __DATE__, __TIME__);‍‍‍‍‍‍‍‍‍‍‍‍ Experiment 1: RAM Target         Demo code: Hello world (From the SDK), modifying the hello world code in below way. PRINTF("hello world. RAM Target \r\n"); PRINTF("hello world, %s, %s.\r\n", __DATE__, __TIME__);‍‍‍‍‍‍‍‍‍‍      Note: Setting the Reset: Core when debugging the demo Fig2 Setting the Reset: Core Running testing: As the Fig3 illustrates, it would print the below message when debugging the demo, however, after reset, it would run the plain load image which is programmed before, as the RAM lost the hello world demo. Fig3 RAM Target runing testing Experiment 2: Plain Load Image        Demo code: Hello world (From the SDK), modifying the hello world code in below way. PRINTF("hello world. PLAIN LOAD IMAGE \r\n"); PRINTF("hello world, %s, %s.\r\n", __DATE__, __TIME__);‍‍‍‍‍‍‍‍‍‍‍‍‍      Download image to external flash:        1. Build the demo to generate a bin file.           This plainload example linked the vector table to 0x00000000, but program to external flash 0x10000000.        2. Program the bin file to external on board flash via SEGGER J-FLASH Lite(V6.22 or higher):             a. Open SEGGER J-FLASH Lite, select device LPC54018.             b. Click the 'Erase Chip' to erase the extrenal flash.(if can not success, press SW4 button and reset the board, and try to erase again)                 Note: if can not success( press SW4 and reset the board, and try to erase again) Fig4 Erase the external flash              c. Select the bin data file, set the '.bin/Erase Start' address to 0x10000000, then click 'Program Device' Fig5 Program the external flash Running testing: Fig6 illustrates the result of  running the plain load image. Fig6 Plain load image runing testing Experiment 3: XIP Image        Demo code: Hello world qspi_xip (From the SDK), modifying the code in below way. PRINTF("hello world. PLAIN LOAD IMAGE \r\n"); PRINTF("hello world, %s, %s.\r\n", __DATE__, __TIME__);‍‍‍‍‍‍‍‍‍‍‍‍‍‍      Download image to external flash:        1. Build the demo to generate a bin file.        2. Program the bin file to external on board flash via SEGGER J-FLASH Lite(V6.22 or higher):            a. Open SEGGER J-FLASH Lite, select device LPC54018.            b. Click the 'Erase Chip' to erase the extrenal flash.(if can not success, press SW4 button and reset the board, and try to erase again)            Note: if can not success( press SW4 and reset the board, and try to erase again) Fig7 Erase the external flash           c. Select the bin data file, set the '.bin/Erase Start' address to 0x10000000, then click 'Program Device' Fig8 Program the external flash      Running testing:      Fig9 illustrates the result of  running the plain load image. Fig9 XIP image runing testing  

The ADC converter for LPC55Sxx is a new IP, it has a lot of new features. The ADC converter clock frequency must be less than 24MHz, the ADC converter sampling rate can reach up to 1MSPS, the ADC converter supports to sample both the single-end analog signal and differential analog signal. It supports software triggering mode and hardware triggering mode, the triggering source can be from internal Timer, external pins, comparator output signal. The ADC converter supports synchronous sampling for only single-ended analog channel, but the analog channel pair are fixed for example CH0A/CH0B and CH1A/CH1B. The ADC of LPC55S6x consist of 16 Trigger Control (TCTRLa) registers, one trigger control register corresponds one hardware trigger source. For example, the TCTRL[0] corresponds trigger source0 GPIO irq_pint[0], the TCTRL[1] corresponds trigger source1 GPIO irq_pint[1]. When the GPIO IRQ_PIN[0] signal edge is detected, the ADC will be trigger to convert the analog channel. Hardware trigger Mapped to 0 GPIO irq_pint[0] 1 GPIO irq_pint[1] 2 State Configurable Timer (SCT) sct0_outputs[4] 3 State Configurable Timer (SCT) sct0_outputs[5] 4 State Configurable Timer (SCT) sct0_outputs[9] 5 State Counter Timer (CTIMER) ct0_mat3_out 6 State Counter Timer (CTIMER) ct1_mat3_out 7 State Counter Timer (CTIMER) ct2_mat3_out 8 State Counter Timer (CTIMER) ct3_mat3_out 9 State Counter Timer (CTIMER) ct4_mat3_out 10 Comparator 11 ARM tx event 12 GPIO BMATCH   The trigger attributes is defined in the corresponding TCTRLaXX register, when the TCTRLaXX[HTEN]=0, software trigger is enabled, hardware trigger is disabled. Setting the SWTRIG[xx] bit will trigger ADC to start conversion. The TCTRLaXX[TCMD] specifies which command buffer is executed.   There are 15 command buffers (CMDa), each consists of  two 32-bit registers (CMDLa:CMDHa), which specifies the ADC channels, resolution, sampling time.. For all the examples, a hardware triggering mode example is developed, the hardware triggering source 7 “State Counter Timer (CTIMER) ct2_mat3_out” is used to trigger ADC, so TCTRL[7] register is initialized, the TCMD bits in TCTRL[7] register is set up as 1, so the CMDH[1]:CMDL[1] are initialized to configure the analog channel, ADC sample resolution… .  

The documentation discusses how to generate phase-shift PWM signals based on SCTimer/PWM module, the code is developed based on MCUXpresso IDE version 10.3 and LPCXpresso5411x board. The LPC family has SCTimer/PWM module and CTimer modules, both of them can generate PWM signals, but only the SCTimer/PWM module  can generate phase-shift PWM signals. In the code, only the match registers are used to generate events, I/O signals are not used.  The match0 register is set up as (SystemCoreClock/100), which determines the PWM signal frequency. The the match1 register is set up as 0x00, which generate event1. The the match2 register is set up as (SystemCoreClock/100)/2;, which generate event2. The duty cycle is (SystemCoreClock/100)/2-0x00= (SystemCoreClock/100)/2, which is 50% duty cycle, the cycle time is (SystemCoreClock/100). The event1 sets the SCT0_OUT1, event2 clears the SCT0_OUT1, so SCT0_OUT1 has 50% duty cycle. The the match3 register is set up as (SystemCoreClock/100)/4;, which generate even3. The the match4 register is set up as 3*(SystemCoreClock/100)/4, which generate event4. The duty cycle is 3*(SystemCoreClock/100)/4  -  (SystemCoreClock/100)/4= (SystemCoreClock/100)/2, which is 50% duty cycle. The event3 sets the SCT0_OUT2, event4 clears the SCT0_OUT2, so SCT0_OUT2 has 50% duty cycle. The phase shift is (SystemCoreClock/100)/4 - 0x00= (SystemCoreClock/100)/4, which corresponds 90 degree phase shift. PWM initilization code: //The SCT0_OUT1 can output PWM signal with 50 duty cycle from PIO0_8 pin //The SCT_OUT2 can output PWM signal with 50 duty cycle fron PIO0_9 pin //The SCT0_OUT1 and SCT0_OUT2 PWM signal has 90 degree phase shift. void SCT0_PWM(void) {     SYSCON->AHBCLKCTRL[1]|=(1<<2); //SET SCT0 bit     SCT0->CONFIG = (1 << 0) | (1 << 17); // unified 32-bit timer, auto limit     SCT0->SCTMATCHREL[0] = SystemCoreClock/100; // match 0 @ 100 Hz = 10 msec     SCT0->EVENT[0].STATE = 0xFFFFFFFF; // event 0 happens in all states     //set event1     SCT0->SCTMATCHREL[1]=0x00;     SCT0->EVENT[1].STATE = 0xFFFFFFFF; // event 1 happens in all states     SCT0->EVENT[1].CTRL = (1 << 12)|(1<<0); // match 1 condition only     //set event2     SCT0->SCTMATCHREL[2]=(SystemCoreClock/100)/2;     SCT0->EVENT[2].STATE = 0xFFFFFFFF; // event 2 happens in all states     SCT0->EVENT[2].CTRL = (1 << 12)|(2<<0); // match 2 condition only     //set event3     SCT0->SCTMATCHREL[3]=(SystemCoreClock/100)/4;     SCT0->EVENT[3].STATE = 0xFFFFFFFF; // event 3 happens in all states     SCT0->EVENT[3].CTRL = (1 << 12)|(3<<0); // match 3 condition only     //set event4     SCT0->SCTMATCHREL[4]=3*(SystemCoreClock/100)/4;     SCT0->EVENT[4].STATE = 0xFFFFFFFF; // event 4 happens in all states     SCT0->EVENT[4].CTRL = (1 << 12)|(4<<0); // match 4 condition only     //PWM output1 signal     SCT0->OUT[1].SET = (1 << 1); // event 1 will set SCT1_OUT0     SCT0->OUT[1].CLR = (1 << 2); // event 2 will clear SCT1_OUT0     SCT0->RES |= (3 << 2); // output 0 toggles on conflict     //PWM output2 signal     SCT0->OUT[2].SET = (1 << 3); // event 3 will set SCT1_OUT0     SCT0->OUT[2].CLR = (1 << 4); // event 4 will clear SCT1_OUT0     SCT0->RES = (3 << 4); // output 0 toggles on conflict     //PWM start     SCT0->CTRL &= ~(1 << 2); // unhalt by clearing bit 2 of the CTRL } Pin initialization code: //PIO0_8 PIO0_8 FC2_RXD_SDA_MOSI SCT0_OUT1 CTIMER0_MAT3 //PIO0_9 PIO0_9 FC2_TXD_SCL_MISO SCT0_OUT2 CTIMER3_CAP0 - FC3_CTS_SDA_SSEL0 void SCTimerPinInit(void) {     //Enable the     SCTimer clock     SYSCON->AHBCLKCTRL[0]|=(1<<13); //set IOCON bit     //SCTimer pin assignment     IOCON->PIO[0][8]=0x182;     IOCON->PIO[0][9]=0x182;     IOCON->PIO[0][10]=0x182; } Main Code: #include <stdio.h> #include "board.h" #include "peripherals.h" #include "pin_mux.h" #include "clock_config.h" #include "LPC54114_cm4.h" void SCT0_Init(void); void SCTimerPinInit(void); void P1_9_GPIO(void); void SCT0_PWM(void); int main(void) {       /* Init board hardware. */     BOARD_InitBootPins();     BOARD_InitBootClocks();     BOARD_InitBootPeripherals();     printf("Hello World\n");    // SCT0_Init();    // P1_9_GPIO();     SCTimerPinInit();     SCT0_PWM();     /* 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 ; } The Yellow channel is PIO0_8 pin output signal, which is SCT0_OUT1 PWM output signal. The Bule channel is PIO0_9 pin output signal, which is SCT0_OUT2 PWM output signal.

Hi: Since LPC series ADC has sequence function, so implement multi-channel ADC transfer is easy. But use DMA is also meaning, so there are two demos to show how to use such applications 1.lpc_multi-channels_adc_dma_sw_trg Use SW trigger multi channels ADC transfer, but use DMA to transfer result to result array. use don't need to care the channel result register, but fetch data from global data register; 2.lpc_multi-channels_adc_dma_hw_trg for many cases, user need to trigger ADC multi channels transfer periodly, and collect enough data for processing. so this demo use SCT_OUT7 to trigger ADC Sequence A for 6 channels, then after 1024 rounds, generate DMA interrupt to process all 6*1024 data array. all demos are implemented on SDK2.6.0 

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

A vulnerability (CVE-2022-22819) has been identified on select NXP processors by which a malformed SB2 file header sent to the device as part of an update or recovery boot can be used to create a buffer overflow. The buffer overflow can then be used to launch various exploits. Refer to the attached bulletin for more information.   09/26/2022 - Bulletin updated to include fix datecode information. 11/01/2022 - Bulletin updated with clarification that mixed datecodes are RT600 only.    

This article introduces how to create a custom board MCUXpresso SDK and how to use it, mainly includes three parts: Part1: Generating a Board Support Configuration (.mex) Part2: Create a Custom Board SDK Using the Board SDK Wizard Part3. Using the Custom SDK to Create a New Project   Requirements: MCUXpresso IDE v11.1.1, MCUXpresso SDK for LPC845, LPC845-BRK board. This method works for all NXP mcu which support by MCUXpresso SDK. About detail steps, please refer to attachment. Thanks!

1    introduction The doc demonstrates how to use MRT(Multi-rate Timer) module to implement the delay function, the delay time is programmable. The MRT has a One-shot stall mode, with the mode, while the MRT channel counter counts down, the core stalls until the MRT channel counter reaches to zero. After the MRT channel counter reaches to zero, the MRT channel becomes idle, the core continues to work.   2 delay function description Sometimes, it is expected that there is a programmable delay between two instructions, for example Instruction 1 Delay Instruction 2 In general, the delay function can be implemented by forcing the core to execute __asm(“NOP”) instructions This code is like: Void delay(uint32_t interval) {        Uint32_t counter;        Counter=ConvertTimeToCounter(interval);        For(uint32_t i=0; i<counter); i++)        {        __asm(“nop”)        } }   The macro convertTimeToCounter is used to convert a time to a number of loop   1.   MRT feature The MRT module of LPC family provides a unique feature called One-shot stall mode, because the test is based on LPC55S69-EVK board, so I referred to the section 27.5.3 One-shot stall mode in UM11126.pdf. The MRT does not have external pad.   One-shot stall mode: Bus stall mode can be used when a short delay is need between two software controlled events, or when a delay is expected before software can continue. Since in this mode there are no bus transactions while the MRT is counting down, the CPU core stalls, consumes a minimum amount of power during that time until the MRT counter reaches to zero. Therefore the One-shot stall mode of MRT can make core stall during the MRT counting down process, the delay function can be implemented.   3 MRT clock source and delay time For the LPC55S69, the clock source of MRT module is the AHB Bus clock, which is the same as the core clock. For the LPC55S69 example, there is the code to set up the core clock void BOARD_InitBootClocks(void) {     BOARD_BootClockPLL150M(); } So the  MRT clock frequency is 150MHz.       The delay time is a time, but the MRT is a counter, so the delay time must be converted to the counter value. The counter value is dependent on the MRT clock frequency. The MRT clock source is AHB bus clock, or the core clock. The LPC55S69 core clock frequency is 150Mhz, so we can define #define MRT_CLOCK_FREQUENCY 150MHz If the required delay time is delay_time variable in second unit, the required MRT counter value is   MRT counter value=delay_time/(MRT clock cycle time)=delay_time* MRT_CLOCK_FREQUENCY.   For example, assume the required delay_time is 1mS or 1*10**(-3)  Second, the corresponding counter value is 1*(10**-3)*150*(10**6)=150 000   The MRT delay time restriction. The MRT counter register is 24 bits, the maximum counter value is 2**24= 16,777,216, the maximum delay time is 16777216/(150*10**6)=0.111848 S or 111 mS.     3 source code description MRT delay function source code is based on SDK package SDK_2_11_1_LPCXpresso55S69.zip, the tools is MCUXpresso IDE v11.5.0. The example is run on LPC55S69-EVK The example uses MRT to delay 100mS(0.1 Second), after the delay, a LED is toggled The MRT counter value is 0.1S*150*(10**6)=15 000 000   For the mrt_init() api function, it initializes the MRT and set the MRT channel0 in OneShotStall mode. Once the core executes the line MRT_StartTimer(MRT0, kMRT_Channel_0, 15000000); the MRT channel0 counter will count down from 15000000, during the counting process the Cortex-M33 will stall. After the counter reach to ZERO, the core finishes the stalling mode and continues to execute the next line, the MRT channel0 counter will be in idle mode.       /**  * @file    LPC55S69_Project_mrt_stall.c  * @brief   Application entry point.  */ #include <stdio.h> #include "board.h" #include "peripherals.h" #include "pin_mux.h" #include "clock_config.h" #include "LPC55S69_cm33_core0.h" #include "fsl_debug_console.h" #include "fsl_mrt.h" #include "fsl_iocon.h"   /* TODO: insert other include files here. */ #define BOARD_LED_PORT BOARD_LED_BLUE_GPIO_PORT #define BOARD_LED_PIN  BOARD_LED_BLUE_GPIO_PIN /* TODO: insert other definitions and declarations here. */ void mrt_init(void); /*  * @brief   Application entry point.  */ int main(void) {       /* Init board hardware. */     BOARD_InitBootPins();     BOARD_InitBootClocks();     BOARD_InitBootPeripherals(); #ifndef BOARD_INIT_DEBUG_CONSOLE_PERIPHERAL     /* Init FSL debug console. */     BOARD_InitDebugConsole(); #endif     mrt_init();     PRINTF("Hello World\n");     for(;;)     {     MRT_StartTimer(MRT0, kMRT_Channel_0, 15000000);     GPIO_PortToggle(GPIO, BOARD_LED_PORT, 1u << BOARD_LED_PIN);     __asm("nop");       }     /* Force the counter to be placed into memory. */     volatile static int i = 0 ;     /* Enter an infinite loop, just incrementing a counter. */     while(1) {         i++ ;         /* 'Dummy' NOP to allow source level single stepping of             tight while() loop */         __asm volatile ("nop");     }     return 0 ; }   uint32_t mrt_clock; mrt_config_t mrtConfig; void mrt_init(void) {           /* mrtConfig.enableMultiTask = false; */         MRT_GetDefaultConfig(&mrtConfig);           /* Init mrt module */         MRT_Init(MRT0, &mrtConfig);           /* Setup Channel 0 to be repeated */         MRT_SetupChannelMode(MRT0, kMRT_Channel_0, kMRT_OneShotStallMode);           //MRT_StartTimer(MRT0, kMRT_Channel_0,  15000000);   }       }                                                                                                              When the above code is running, user can see the blue LED toggles on the LPC55S69-EVK board. Connecting the PIO1_4 pin signal ( the pin 5 of P18 connector) on LPC55S69-EVK, the PIO1_4 signal toggling frequency is 5Hz, the cycle time is 200mS, so the delay is 100mS.      

This article mainly introduces how to use CTIMER measuring pulse-width in LPC845, in fact, it can applies to all LPC products  including CTIMER modules. 1  CTIMER has below features: A 32-bit timer/counter with a programmable 32-bit prescaler. Four 32-bit match registers that allow interrupt generation on  match. The timer and prescaler may be configured to be cleared on a designated capture event. This feature permits easy pulse width measurement by clearing the timer on the leading edge of an input pulse and capturing the timer value on the trailing edge.(This article mainly use this feature.) Up to four match registers can be configured for PWM operation.   2 Introduction There is neither pulse-width measurement nor input capture demo under SDK, so write this article and related code for this topic. The principle is clearing the timer and prescaler on the leading edge of an input and capturing the timer valued on the trailing edge.   3  Main steps   Step1 Choose CAP input channel, capture edge, and enable interrupt if needed. Using “Capture control register”. The Capture control register is used to control whether one of the four capture registers is loaded with the value in the timer counter when the capture event occurs, and whether an interrupt is generated by the capture event. Setting both the rising and falling bits at the same time is a valid configuration, resulting in a capture event for both edges. In the description below, n represents the timer number, 0 or 1. In this example, choose capture channel 0 as input channel, falling edge as capture edge, and enable capture interrupt. SDK code: CTIMER_SetupCapture(CTIMER,CTIMER_CAP0_INT,  CTIMER_CAP_FALL,TRUE); Step2 Select which capture input edge will cause the timer and pre-scaler to be cleared. Using “Count control register”. The Count Control Register (CTCR) is used to select between timer and counter mode, and in counter mode to select the pin and edge(s) for counting. When counter mode is chosen as a mode of operation, the CAP input (selected by the CTCR bits 3:2) is sampled on every rising edge of the APB bus clock. After comparing two consecutive samples of this CAP input, one of the following four events is recognized: rising edge, falling edge, either of edges or no changes in the level of the selected CAP input. The timer counter register is incremented only if the identified event occurs and the event corresponds to the one selected by bits 1:0 in the CTCR register. Effective processing of the externally supplied clock to the counter has some limitations. Since two successive rising edges of the APB bus clock are used to identify only one edge on the CAP selected input, the frequency of the CAP input cannot exceed one half of the APB bus clock. Consequently, duration of the HIGH/LOWLOW levels on the same CAP input in this case cannot be shorter than 1/APB bus clock. Bits 7:4 of this register are also used to enable and configure the capture-clears-timer feature. This feature allows for a designated edge on a particular CAP input to reset the timer to all zeros. Using this mechanism to clear the timer on the leading edge of an input pulse and performing a capture on the trailing edge, permits direct pulse-width measurement using a single capture input without the need to perform a subtraction operation in software. In this example, we choose timer mode, configure Channel 0 rising edge clearing the timer, enable clearing of the timer and the pre-scaler. SDK code:   CTIMER->CTCR = CTIMER_CTCR_CTMODE(0)|CTIMER_CTCR_SELCC(1)   |CTIMER_CTCR_ENCC_MASK ; Step3 Read pulse-width value from “Capture register”. Each Capture register is associated with one capture channel and may be loaded with the counter/timer value when a specified event occurs on the signal defined for that capture channel. The signal could originate from an external pin or from an internal source.   SDK code: CTIMER_GetCAPCounter(HW_CTIMER0, HW_CTIMER_CH0); We can read capture value on capture interrupt. Detail code please refer to attached project, it based on MCUXpresso IDE v11.3, SDKv2.9, LPCxpresso845MAX board.   4  Test Result Input a signal as below into channel 0 (P1_0), pulse width is 10us. Print the measurement results on Console view of MUXpresso IDE:        

Do you want to know more about one of our hottest products in the LPC800 series portfolio? Take a look at this technical presentation featuring the LPC84x MCU family. Based on the Arm Cortex-M0+ core, the LPC84x Family of MCUs is a low-cost, 32-bit MCU operating at frequencies of up to 30 MHz. The LPC84x MCU family supports of up to 64 KB of flash memory and 16 KB of SRAM. In addition, to make things easier, the LPC800 series McUs are supported by our free example code bundles and now, they're also supported by the MCUXpresso Software Develpment Kit (SDK).  Fig 1. LPC84x MCU Family Block Diagram