Getting Started with LPCXpresso54608 & MCUXpresso is pretty straight forward, but we want to make the process even easier. So we created a simple guide to walk you through the getting started process, LPCXpresso54608: Out of Box & Getting Started Introduction LPC5460x MCU Family part numbering & feature summary table (highlighted in yellow are the first of many parts to be released). If it wasn't already clear, LPCXpresso54608 is the superset development board for our LPC5460x MCU Family. NXP.com Board Page Board Part Number (OM13092) Board User Manual (UM11035) Board Schematics Key features of the LPCXpresso54608 development board, 272x480 color LCD with capacitive touch screen On-board, high-speed USB, Link2 debug probe with CMSIS-DAP and SEGGER J-Link protocol options UART and SPI port bridging from LPC546xx target to USB via the on-board debug probe Support for external debug probe 3 x user LEDs, plus Reset, ISP (3) and user buttons Multiple Expansion options, including Arduino UNO and PMod Built-in power consumption measurement for target LPC546xx MCU 128Mb Micron MT25QL128 Quad-SPI flash 8MB Micron MT48LC8M16A2B4 SDRAM Knowles SPH0641LM4H digital microphone Full size SD/MMC card slot NXP MMA8652FCR1 accelerometer Stereo audio codec with line in/out High and full speed USB ports with micro A/B connector for host or device functionality 10/100Mbps Ethernet (RJ45 connector)
First, download the LPCXpresso54608 board User Manual. After scanning the document, let's get started! Plug in LPCXpresso54608 (as shown below). You will see the pre-loaded, Out of Box demo, which features Draupner TouchGFX. A screen shot is shown below, Once you've explored the pre-loaded demo, you will likely want to learn more. For this you will need to configure and build an MCUXpresso Software Development Kit (SDK) for your LPCXpresso54608 development board. Register or use your login credentials to sign in and download software from NXP. You can create a configuration for the LPCXpresso54608 in one of two ways: By typing 'LPCXpresso54608' or selecting boards>LPC>LPCXpresso54608 Once you have selected the board you will be presented with two options: 'Select Configuration' or 'Specify Additional Configuration Settings'. (It is recommended that you name the configuration something that specifies the settings as this will help identify multiple configurations.) Note: By default the SDK Builder will choose IAR as the default toolchain for Windows. For this tutorial we will use Windows as our Development Host OS. If this is not the desired toolchain or OS please 'Select 'Specify Additional Configuration Settings' The following window will be presented, which allows you to download an SDK for IAR, Keil or Both (selecting 'All toolchains'.). During this stage, you can also specify any necessary middleware for your download. You can select or deselect these under the 'Select Optional Middleware' Select 'Go to SDK builder' once you have made your choices. Note:You may be prompted to update your info before you are allowed to download the package. If this happens select the link in the red at the top to resolve any issues. Once the information is updated you can click on the 'Overview' at the top and reselect 'SDK Builder' to return to the screen you were on. You have the opportunity to rename your file one last time before you hit download now. Once you select 'Download Now' you will be presented with a license agreement and once agreed to the download will start. Once you have downloaded the packaged .zip use your favorite utility to extract to a known location --> Continue here if IAR is your selected default toolchain. --> Continue here if KEIL is your selected default toolchain. --> Continue here if MCUXpresso is your selected default toolchain (coming March 2017!)
Now that you've downloaded & unzipped your LPCXpresso54608 SDK, let's open KEIL uVision IDE. Note: you must have at least uVision version 220.127.116.11 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!
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
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:
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:
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:
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:
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:
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:
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.
1. Problem description
When we debug a new designed LPC55 custom board through SWD, if IDE throws out error messages such as connection failure or no available device being found, normally we must check below two points:
Whether the debug circuit design is correct.（ https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/Design-Considerations-for-Debug/m-p/469565#M44 ）
Whether LPC55 power supply system is correct.
Regarding to the second point of power supply system, we received many feedback from customers that even they read UM for times they still can’t well-understand LPC55xx DCDC power supply system. Therefore we prepare this article to analyze LPC55xx power supply circuit and introduce detection method.
2. Problem Analysis
The difference of power supply circuit between LPC55xx series and other LPCs is that LPC55xx uses DCDC circuit inside to provide core voltage. It lowers the input 1.8V-3.6V voltage to around 1.1V to supply LPC55xx internal system. The DCDC converter is efficient and reduces the internal power consumption. The disadvantage is that it generates a certain ripple.
LPC55xx power supply circuit is as follows:
In order to analyze, We divide LPC55xx power supply circuit into 4 regions and will introduce them one by one according to the different functions.
1) Input voltage: In this part, VBAT_PMU provides input voltage to RTC and internal analog components. VBAT_DCDC provides input voltage to internal DCDC circuit.
2) A set of filter capacitors: To filter out the burrs and glitch at the voltage input.
3) DCDC circuit: Work with LPC55xx internal DCDC circuit together to generate 1.1V output voltage.
4) VDD_PMU: Provides the 1.1V output voltage of the DCDC circuit to the LPC55xx core.
Note: The design of region 3 is to work with the internal DCDC converter. The inductance L1 of 4μ7H and the capacitance C1 of 22μF are calculated by LPC55xx internal circuit. When designing, we must strictly follow the parameters recommended in the manual, otherwise DCDC circuit can’t work normally.
3. DCDC Circuit Detection
LPC55xx power supply system current direction is shown in the diagram below. See arrow in red. In order to ensure the normal operation of the DCDC circuit, the following two detection points are recommended.
1) Detection point 1: External 1.8 to 3.6V voltage input, normally it’s 3.3V.
2) Detection point 2: Output of the DCDC converter. If the DCDC works normally, we can get 1.1V voltage output here. The output voltage supplies power to the core components such as the central processing unit through the VDD_PMU.
If DCDC convert input is correct but output wrong, we suggest checking inductor L1 and the capacitor C1 and related solder issue. If the voltage of two detection points are correct, the power supply circuit problem can be ruled out.
For custom designed LPC55xx board, if SWD design is correct and power supply system works well, IDE can connect, download and debug target without issue.
1. Introduction 1 2. USB Demo based on MCUXpresso SDK 1 2.1 Update USB device demo: USB0->USB1 2 2.2 Update USB host demo: USB0->USB1 2 2.3 Update USB ROM demo: USB0-> USB1 3 3. USB Demo based on LPCOpen 3 4. Notes and Recap 4
Most of LPC devices integrate USB module. NXP LPC currently integrates full-speed USB (FS, Full Speed, 12Mbps) and high-speed (HS, High Speed, 480Mbps) USB.
Specifically, for the LPC series:
- Some LPCs such as LPC55xx and LPC54xxx integrate both HS USB and FS USB. Usually USB0 is FS USB and USB1 is HS USB.
- Some LPCs such as LPC43xx and LPC18xx integrate two HS USBs, so USB0 and USB1 are both HS USBs.
The two most well-known NXP software packages for LPC series are MCUXpresso SDK and LPCOpen. MCUXpresso SDK is mainly for LPC products launched in recent years, while LPCOpen is used for earlier LPC derivatives. The USB demos included in these two packages run on USB0 by default.
Most of NXP USB demos are for USB0 by default. This article is to introduce how to switch a USB0 demo to USB1 demo based on different software packages.
2. USB Demo based on MCUXpresso SDK
(e.g. LPC54XXX, LPC55XX)
The MCUXpresso SDK USB demo codes are categorized as:
- USB as Device: e.g. usb_device_cdc_vcom, usb_device_hid_generic, etc.
- USB as Host: e.g. usb_host_hid_mouse, usb_host_msd_fatfs, etc.
- USB demo based on USB ROM API: e.g. usb_rom_device_audio,usb_rom_device_cdc, etc.
2.1 Update USB device demo: USB0->USB1
Taking usb_device_cdc_vcom demo as an example. To switch to USB1, simply change the corresponding code in usb_device_config.h file as follows.
/*! @brief LPC USB IP3511 FS instance count*/
#define USB_DEVICE_CONFIG_LPCIP3511FS (0U)
/*! @brief LPC USB IP3511 HS instance count*/
#define USB_DEVICE_CONFIG_LPCIP3511HS (1U)
After the change, recompile the program to run. The program was updated to USB1 device demo.
2.2 Update USB host demo: USB0->USB1
Taking usb_host_hid_mouse demo code as an example, to switch to USB1, modify the macro definition in usb_host_config.h as follows:
#define USB_HOST_CONFIG_OHCI (0U)
#define USB_HOST_CONFIG_IP3516HS (1U)
The program is recompiled and run. The program was updated to USB1 host demo.
2.3 Update USB ROM demo: USB0-> USB1
( e.g. LPC54XXX Series)
USB ROM demo calls the USB ROM API, there is no way to switch the default USB0 to USB1 by modifying macro definitions. In order to update code to USB1 demo, the recommended steps are as below:
-USB HS DEVICE and USB PHY clock configuration
-Change to use USB HS ISR
-Locate the related buffer into USB RAM.
-Set the USB ROM handle to be HS
If user has difficulties in revising the code by self, user can apply demo code from NXP LPC online support team by creating a private case.
3. USB Demo based on LPCOpen
(e.g. LPC43XX, LPC18XX)
Some legacy LPCs run on LPCOpen, such as LPC43xx series, LPC18xx series. Their USB0 and USB1 are both high-speed. The default USB demo is for USB0 as well. To switch to USB1, we can uncomment #define USE_USB1 and comment #define USE_USB0 in app_usbd_cfg.h.
// #define USE_USB0
Taking usbd_rom_cdc_uart demo as an example:
Recompile and run, the program is updated to USB1 demo.
4. Notes and Recap
The focus of this article is on software modification of converting USB0 to USB1 on NXP SW package. Regarding the hardware, customer needs to check the specific demo board user guide. For example, when we use HS USB, it may be necessary to provide an external power supply, and the jumper also needs to be adjusted to build a well hardware environment for HS USB operation. I will not dwell on them here.
This article summarizes methods of switching USB0 to USB1 for several commonly used LPC series on MCUXpresso SDK and LPCOpen package. customers who need USB1 demo code can find the corresponding modification methods in this article for their own software and chips. Official routines are only used for demo board demos and chip learning. If for commercial usage, user needs to learn USB in depth and be responsible for own application.
[LPC546xx] Understanding ECRP
Code protection is usually considered at the last step during developing stage. The purpose is to protect our code being hacked when the product is released to market. For example, using ECRP to disable SWD debug interface, disable ISP, disable mass erase, etc.
1. ECRP vs Legacy CRP
ECRP (Enhanced Code Read Protection) is versus legacy CRP on early LPC devices. We can consider ECRP as an advanced version of CRP.
Comparing with CRP, ECRP adds new protection features:
− Block ISP via Pins
− Block ISP using IAP
− Block SWD
− Mass Erase enable/disable
− Sector protection
This table lists the difference of ECRP vs. CRP from Anti-Tampering and Flexible view.
2. Understand and implement ECRP
ECRP allows user to tenable below features:
− Protect FLASH from ISP Erase/Write
− Protect FLASH from IAP Erase/Write
− Enable/Disable ISP Entry from bootloader
− Enable/Disable ISP Entry from IAP call
− Enable/Disable SWD Enable/Disable
It looks easy but it is important to know that ECRP feature is controlled by both FLASH and OTP configuration! The most restrictive combination in both setting is needed
2.1 Where is FLASH ECRP:
ECRP is at 0x20 of vector table, it’s uint32_t type. We write to this address to set FLASH ECRP protection. The valid bits of FLASH_ECRP is 0-17bit, and the default value is 0xFFFF_FFFF. For detail, please see UM.
2.2 Where is OTP ECRP
OPT is a non-volatile and write-once register. OTP is not FLASH and it can be ONLY written by IAP function. OPT ECRP configuration is at OPT bank 3. The default OTP ECRP value is 0.
2.3 FLASH ECRP + OTP ECRP Decides the Protection.
See this table to show the combination.
Here OTP ECRP is always set with higher priority than FLASH ECRP!
Here is typical ECRP settings
2.4 Be Attention!
The part is permanently disabled when
On-chip Image(s) are ruined
SWD access prohibited
ISP entries prohibited
Please be attention when testing ECRP feature, mis-operation may make the chip brick!
LPC: Regarding to Internal Clock Calibration
In MCU development, using the internal crystal oscillator as a clock source instead of the external crystal oscillator can save costs. But the clock frequency generated by the internal crystal oscillator is affected by temperature and MCU frequency more than external crystal oscillator. Many customers have questions about the internal clock accuracy, whether the internal clock can be used for USB transmission, and how to calibrate the internal clock. This article mainly explains this.
1. Calibrate internal clock by FREQTRIM
Normally, we can only calibrate the internal clock by adjusting the FREQTRIM value.
The internal clock frequency is affected by temperature, MCU frequency and other factors. The FRO control register can calibrate the internal clock, as follows:
The FREQTRIM register value ranges from 0 to 255, and each adjustment step is about 0.1% of the internal clock frequency. There is no precise formula to express the relationship between the FREQTRIM value and the FRO frequency. The ideal FREQTRIM value can only be determined by adjusting FREQTRIM in code and observing FRO output waveform with oscilloscope.
Test and observation:
The following is the test result. It shows how FRO frequency varies with FREQTRIM increasing from 0-255.
Test result of first development board:
Test result of second development board:
The following two points can be seen from test results:
- There is no linear relationship between the FRO clock frequency and the FREQTRIM register value, and there is no precise formula to express the relationship between them;
- Even for chips of the same part number, the internal clock frequency changes are slightly different, with the FREQTRIM register value changing, but the trend is same.
Therefore, there is no precise formula to guide internal clock frequency calibration. You can only adjust the FREQTRIM register value repeatedly, just like adjusting the focus of a projector. Use an oscilloscope to check the frequency of the internal clock pin to find the most suitable FREQTRIM register value.
There is same solution for FRO clock frequency calibration about other LPC chips.
2. LPC51U68: Software calibration USB transmission when using internal clock source
The Full Speed USB module of LPC51U68 has a unique FRO automatic calibration function, which automatically adjusts the FREQTRIM value to achieve FRO calibration by measuring the USB SOF bit. Once FRO is calibrated, the corresponding system clock and peripheral clock are calibrated. This solution is only applicable to LPC51U68, please refer to the user manual for other chips.
The following is the FRO clock accuracy described in LPC51U68 User Manual, which is ± 1%:
For Full Speed USB, the USB data transmission accuracy requirement is ±0.25%, and the FRO clock accuracy is not satisfied. NXP provides a software solution to calibrate FRO by measuring the first packet of frame (SOF), which can meet the transmission accuracy in Full Speed mode.
The solution download link is as follows:
After LPC54XXX enter ISP mode, there are two methods to upgrade the application through UART/I2C/SPI/USB. One method is to change the ISP pin state when power on, and the other method is to reinvoke ISP Boot ROM in source code during code running. The first method does not require user to write any code, and the operation is simple, but the disadvantage is that it is not flexible and is not suitable for on-site operation; The second method is more flexible and is widely used in Secondary Bootloader applications developed by yourself, but it requires users to write their own code.
In actual development, because the USB port of personal computer is easy to use, the method of using the USB port for application upgrade is becoming more and more popular. Unfortunately, we currently do not have instructions for upgrading the application by the USB port in ISP mode. So we write this article to share the method here.
There are two methods to enter ISP mode:
Method 1: Enter ISP mode to upgrade the application during power on
On the hardware side, configure the ISP0~2 pins before power-on or reset, and the MCU enters ISP mode to upgrade the application. The pin configuration method is as follows:
Method 2: Activate Reinvoke ISP in source code to upgrade the application
In ISP mode, the application is upgraded through UART/I2C/SPI/USB. This article focuses on the USB method. Here for USB, Both USB0 (Full Speed) and USB1 (High Speed) of LPC54XXX can be used for application upgrade. There are two USB upgrade modes: DFU (Device Firmware Updata) and MSC (Mass Storage Device Class), as follows:
Select the application upgrade mode by modifying byte 0 and byte 1 of the ISP parameter array. The key code is as follows
There are 3 key point we need to pay attention in Figure 3:
-When isp_mode is configured as 0xAA, it is DFU mode, otherwise it is MSC mode (for example, isp_mode is configured as 0xFF).
-When isp_mode is configured as 8, USB FS is used, and when it is configured as 9, USB HS is used.
-Enter the ISP mode through the Chip_IAP_ReinvokeISP function.
2.1 Use DFU for application upgrade
To work with DFU, dfu-util tool is needed to use DFU to upgrade the application, you can download the DFU tool on the DFU official website. The link is as follows:
NXP also includes the dfu-util tool in LPCScrypt. If you have downloaded LPCScrypt, you can use it directly in the bin directory.
DFU update application Steps:
Take LPC54628 as an example, ISP is configured as DUF mode, and USB1 is used to upgrade the application.
Modify the relevant code in Figure 3, as follows:
isp_mode = 0xAA; isp_mode = SL_USBHS;
Build and download the application to the MCU, power on again, and connect USB1 to the computer. Here
Enter the dfu-util tool directory and copy the .bin file to the current directory.
Use the command: ./dfu-util -l Find the DFU devices.
Use the command: ./dfu-util -D .\lpcxpresso54628_gpio_led_output.bin -a 0
Download the lpcxpresso54628_gpio_led_output.bin file to the device with alt number 0. Alt0 is "FLASH", alt1 is "RAM", and the specific operations are as follows:
After downloading the application successfully, reset the MCU and observe the blinking phenomenon of the LED on the development board.
2.2 Use MSC for application upgrade
Take LPC54628 as an example, ISP is configured as MSC mode, and USB1 is used to upgrade the application. Modify the relevant code in Figure 3, as follows:
isp_mode = 0xFF; isp_mode = SL_USBHS;
Build and download the application to the MCU, power on again, and connect USB1 to the computer. You will found another disk in my computer, as follows:
Then do the following to update firmware:
-Remove the original firmware.bin in the CRP DISABLD disk.
-Rename the application (for example, lpcxpresso54628_gpio_led_output.bin) to firmware.bin.
-Copy the application firmware.bin to the CRP DISABLD disk.
-Reset the MCU, if the LED is observed blinking, it proves that the application has been successfully upgraded.
Note: The application must be renamed, and the rename cannot be performed in the CRP DISABLD disk.
Demo project： lpcxpresso54628_flashiap.zip
Application upgrade file：lpcxpresso54628_gpio_led_output.bin (generated by SDK demo code)
Some users cannot access MCU peripherals normally by add peripheral initialization code to MCUXpresso SDK TrusZone demo. For example, when add Flash operation code in the security world, the program code jumps to HardFault_Handler after running to function FLASH_INIT(), and the execution of Flash erase and Flash program operations fails also, as follows:
As shown in figure 2 and figure 3, when the program code runs to code return VERSION_FLASH_API_TREE->flash_init(config), it automatically jumps to HardFault_Handler. VERSION_FLASH_API_TREE is located in the 0x1301fe00 address of the boot rom, the flash erase api is located in address 0x1300413bU, and the flash program api is located in address 0x1300419dU (the corresponding program code is shown in figure 6). All above addresses are not security privilege.
From the 18.104.22.168.2 TrustZone preset data chapter in user manual, after enabling the TrustZone configuration, users must configure the security level of the entire ROM address space to security priority (S-Priv) in order to ensure that the ROM area can be accessed normally by the security area code.
Below is the steps of how to resolve this issue. The demo is based on MCUXpresso SDK demo hello_world_s.
Step 1 : firstly we use the TEE tool integrated with MCUXpresso IDE to configure the security level of the Boot ROM address area, as shown in Figure 8, double-click the Boot-ROM area in the Memory attribution map window, and configure the sector’s security level in the corresponding Security access configuration window on the left.
Step 2: Second, when operating Flash or other peripherals in the security area, users must configure the security level of correlative peripherals to the security priority(S-Priv).
When operating flash in the SDK TrustZone demo, the MCU uses two slave peripherals, so users must configure their security level to S-Priv.
From the usermanual, when operating flash, the system clock frequency cannot exceed 100MHZ.
When using the function of FLASH_Program(), because the s_buffer is 512-byte aligned, the BUFFER_LEN is equal to 512/N.
The above configuration of the security level can be configured through the TEE tool integrated the MCUXpresso IDE. After completing configuration, click Update Code to automatically update the relevant code in the tzm_config.c file, as shown in Figure 10.
The updated code is shown in Figure 11 below. It is obvious that the security level settings of boot rom memory and peripheral (FLASH, SYSCTRL) have changed. If you do not use the TEE tool, you can also manually modify tzm_config.c to configure the same security options.
Third-party tools users:
Because many users are accustomed to using third-party development tools such as Keil or IAR, but these IDEs do not integrate the TEE tool, users need to check the configuration requirements of related registers in user manual when modifying the security level of related areas and peripherals in TrusZone, and update the associated code in the tzm_config.c file (similar to Figure 11) to complete the related configuration. In addition, NXP released the MCUXpresso Config Tools, which integrates MCU-related configuration functions. Users can download and install this tool to perform configurations and update codes. The download link is as follows:
Introduction of MCUXpresso Config Tools
After the tool is installed, open the configuration tool, select Create a new configuration based on an SDK example or hello world project, click Next, as shown in Figure 12:
In Start Development window, follow below steps to generate project. As shown in Figure 13.
After the tzm_config.c file is updated, copy or import it to the corresponding folder of KEIL or IAR third-party development tools, and it can be used normally.
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_t region0, uint32_t 0X0) //generate PRINCE region0 crypto key Status=FFR_KeystoreGetKC(&flashInstance,&keyCode,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,true,&flashInstance) //load IV code to PRINCE status=PRINCE_LoadIV(kPRINCE_Region0,&prince_iv_code) //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
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 >
At the time of the latest update to this article, the latest silicon revision of the LPC55S6x is revision 1B. Since Nov,2019, all the LPCXpresso55S69 EVK boards marked as Revision A2 or A3 are equipped with revision 1B silicon. Initial production boards that have 0A silicon installed are marked Revision A1.
NXP introduced its new debug session request functionality on silicon revision 1B. For some IDE versions, the method of initiating a debug session is designed for current 1B silicon revisions and will r esult in an endless loop when used on older revision 0A parts due to the older revision not implementing some aspects of the handshake protocol. The protocol for this debug connection method, including handling of both 0A and later silicon revisions correctly, is included in the latest LPC55S6x/S2x/2x User Manual, section Debug session protocol.
MCUXpresso IDE v11.0.1, incorrectly only supports silicon revision 1B debug session requests and cannot silicon to revision 0A parts in some situations. When connecting LPCXpresso55S69 Revision A1 board, you may have connection error like this:
NXP released an MCUXpresso IDE v11.0.1 LPC55xx Debug Hotfix1 for this issue. Please follow the steps to fix the issue below if you have to use IDE v11.0.1 with silicon revision 0A; however it is recommended to update to the latest version of the IDE instead of taking this approach:
According to our test:
IAR Embedded Workbench for ARM v8.42 and later can support both silicon revision 1B and 0A production without issue, which can be downloaded from
Note: The IAR 8.50.5 changed the CMSIS-DAP debug support for trustzone feature. There is known debug issue with the combination of IAR 8.50.5+SDK2.8.0. Thus our recommendation is:
Use IAR 8.50.5 with SDK2.8.0
Use IAR 8.40.2 with SDK 2.7.1
Both Keil MDK v5.28 and v5.29+ latest LPC55S69 pack v12.01 can support silicon revision 1B without problem but cannot support silicon revision 0A.
LPC55S69 Revision 0A vs. 1B differences summary
Debug Access handshake
Supported but not required. Handshake signaling partially supported
Secure Boot Revision
Maximum CPU Frequency
IDE revision required
1. MCUXpresso IDE v11.0.0 and older
2. MCUXpresso IDE v11.0.1 + hotfix 1
3. MCUXpresso IDE 11.1 and later
MCUXpresso IDE v11.0.0 and newer
SDK2.5 and newer are supported; SDK2.6.3 and newer are recommended
SDK2.6.3 and newer
LPC55S69 Defect Fix: 0A vs. 1B
Defect : For PRINCE encrypted region, partial erase cannot be performed
Defect : For PUF based key provisioning, a reset must be performed
Defect : Unprotected sub regions in PRINCE defined regions cannot be used.
Defect : Last page of image is erased when simultaneously programming the signed image and CFPA region
Defect : PHY does not auto-power down in suspend mode
For more detail, see Errata sheet LPC55S6x which can be downloaded from NXP web site.
Note that NO BOARDS WERE EVER SOLD THROUGH DISTRIBUTION WITH PRE-PRODUCTION SILICON. In case you have board marked with Revision 1, 2 ,A, or A1 board with 1B silicon, contact NXP to ask for production replacement.
Get Silicon Revision:
The silicon revision info is marked on the chip and board revision is marked on the board silkscreen. For silicon revision marking information, please consult LPC55S6x Data Sheet section 4. Marking . Below is an example of silicon revision marking information where revision is highlighted in red:
The user application can also get the silicon revision through chip revision ID and number: SYSCON->DIEID:
The English and Chinese version documents are attached.
Now that you've downloaded & unzipped your LPCXpresso54608 SDK, let's open IAR Embedded Workbench IDE. Note: You must have at least IAR Embedded Workbench version 22.214.171.12446 to use this board Once open, select File>Open>Workspace Navigate to the location where you unzipped your SDK files. 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! Select boards>lpcxpresso54608>demo_apps>touch_cursor>iar>touch_cursor Once the workspace is loaded, you will see the project files on the left. Along the toolbar the first highlighted item is 'Build' select it. Once your console shows no errors you can select the 'Download and Debug' a few icons to the right of 'Build' Your debug session will start and will look like the following window. Once it opens 'touch_cursor.c' and has a green arrow next to the main function you can select 'Go' After you have successfully flashed the board with this demo you will see the following on your board. 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 following document contains a list of documents, questions and discussions that are relevant in the community based on the amount of views they are receiving each month. If you are having a problem, doubt or getting started in LPC or MCUXpresso you should check the following links to see if your doubt have been already solved in the following documents and discussions. MCUXpresso MCUXpresso Supported Devices Table FAQ: MCUXpresso Software and Tools How to create a new LPC project using LPCOpen and MCUXpresso IDE Introducing MCUXpresso SDK v.2 for LPC54xxx Series Generating a downloadable MCUXpresso SDK v.2 package Using the MCUXpresso Pins Tool MCUXpresso Config Tools is now available! LPC55xx Multicore Applications with MCUXpresso IDE LPC information LPC5460x MCU Family Overview USB with NXP Microcontrollers LWIP memory requirements LPC800 Four-Part Webinar Series! The LPC804 Programmable Logic Unit (PLU) LPC84x Technical Training - Now Available Guides and Examples Flashing and Installing the new firmware and drivers for LPC11U35 debug probes Enabling debug output USB FLASH download, programming, and security tool (DFUSec) DMA Ping-Pong application Getting start with LPCXpresso54608 & emWin Graphics; Capacitive Touch example using the LPC845 Breakout Board OLED Display Application Example using LPC845 Breakout Board and SPI Mixed-Signal Logic Analyzer & Oscilloscope (Lab Tool) Solution LPC FAQ How to calculate the value of crystal load capacitors? Can I send a message with X/Y/Z bits in the ID? What is the difference between error active and error passive? What is the sample point for? How can I verify the configured CAN bitrate, using an oscilloscope?
New update to errata will be published regarding the vendor_usage field in the PFR. In ROM, the 16-bit monotonic counter is implemented in the upper 16 bits of the 32-bit VENDOR_USAGE field and the inverse of the monotonic counter is in the lower 16 bits. Users must take care when using the ROM API to increment the upper end of this field and write the inverse on the lower 16 bits in order for ROM to validate the value correctly.
The initial value that shall be written is 0x0000FFFF. Then the updates will be as follows: 0x0001FFFE 0x0002FFFD . . 0x0005FFFA . . 0x1010EFEF . . 0xFFFF0000
Example Code using ROM API:
*This example demonstrates the increment of the version in CFPA page as well as the vendor usage, it does not cover all use cases, so please use this as a reference only*
PRINTF("Disable Flash Protect...\r\n");
/* Initialize flash driver */
if (FFR_Init(&flashInstance) == kStatus_Success)
PRINTF("Flash init successfull!!. Halting...\r\n");
status = FFR_GetCustomerInfieldData(&flashInstance, (uint8_t *)g_CFPAData, 0x0, FLASH_FFR_MAX_PAGE_SIZE);
PRINTF("Header 0x%08x , Version 0x%08x , SecureFW Version 0x%08x , NonSecureFW Version 0x%08x\r\n", g_CFPAData, g_CFPAData, g_CFPAData, g_CFPAData);
PRINTF("ImageKey Revoke 0x%08x , Reserved 0x%08x , RothRevoke 0x%08x , Vendor Usage 0x%08x\r\n", g_CFPAData, g_CFPAData, g_CFPAData, g_CFPAData);
PRINTF("NS PIN 0x%08x , NS DFLT 0x%08x , Enable FA Mode 0x%08x , Reserved1 0x%08x\r\n", g_CFPAData, g_CFPAData, g_CFPAData, g_CFPAData);
/* Clean-up CFPA area */
g_CFPAData = 0;
g_CFPAData = 0;
/*Increase Monotonic counter*/
p32 = (uint32_t *)(uint32_t)g_CFPAData;
version = p32;
if (version == 0xFFFFFFFFu)
p32 = version;
PRINTF("Version to write: 0x%08x \r\n", version);
/*Increase Vendor Usage*/
uint32_t vendor_usage = p32;
if(vendor_usage == 0x0)
vendorUsage_right = 0xFFFF;
vendorUsage_left = 0x0000;
vendorUsage_right = vendor_usage & 0xFFFF;
vendorUsage_left = vendor_usage >> 16;
vendorUsage_left += 0x1;
vendorUsage_right -= 0x1;
vendor_usage = (vendorUsage_left << 16) | vendorUsage_right;
p32 = vendor_usage;
PRINTF("Vendor_Usage to write: 0x%08x \r\n", vendor_usage);
Status = FFR_InfieldPageWrite(&flashInstance, (uint8_t *)g_CFPAData, FLASH_FFR_MAX_PAGE_SIZE);
if (kStatus_FLASH_Success == Status)
status = kStatus_Success;
PRINTF("CFPA Write Done!\r\n");
status = kStatus_Fail;