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)
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.
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:
Many LPC55 users experienced connection failure when using ISP USB0 for firmware update. In practice, we don’t suggest user updating firmware via ISP USB0 for LPC55(S)6x/ 2x,LPC55(S)1x/0x parts.
LPC55 USB0 is Full Speed USB port. The default setting of CMPA turns off the USB0 port. Some users may reconfigure CMPA to enable ISP USB0 in order to use ISP USB0 BOOT, but this is not recommended in practice.
LPC55 ISP USB0 uses internal FRO as clock source. According to LPC55 data sheet, the FRO accuracy is only +-2%, while the FS USB data rate tolerance specification is +-2500ppm(+-0.25%). Obviously, the LPC55 FRO spec can’t meet the USB0 clock accuracy requirement. See below extraction from NXP manuals.
Fig 1. The accuracy of FRO ( Extracted from LPC55S69 Datasheet )
Fig 2. The accuracy requirement of USB FS( Extracted from TN00063 )
Some users may wonder why USB0 can use internal FRO as clock source in the user application? Whenever internal clock source FRO is used as USB0 clock source, we must calibrate FRO in source code for communication. That’s to say, trim FRO to an accurate frequency. We can see FRO trim in many MCUXPressoSDK USB demos. When using FRO as the USB0 clock source, in order to ensure the USB0 clock accuracy, we must use the USB0 SOF frame synchronization to calibrate the FRO in order to ensure the accuracy of FS USB clock source (reference design of TN00063, TN00063-LPC5500 Crystal-less USB Solution). Unfortunately, the BOOT ROM of LPC55 does not support USB SOF calibrating FRO. As a result, even if we enable ISP USB0, the FRO clock drift can still cause USB0 communication failure under non-room temperature conditions.
Since ISP USB0 is not recommended for firmware update, the user manual no longer announces the enablement bit of ISP USB0 in CMPA. If you need to use USB0 for firmware update, we recommend using ISP USB1 (High Speed USB), because USB1 uses accurate external clock source which can ensure the ISP USB1 working stable.
In addition, the communication protocol of ISPUSB complies with BLHOST specification. For details, see: blhost User's Guide - NXP
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
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;