LPC1700 Secondary USB Bootloader: Rev. 01 - 8 September 2009 Application Note
LPC1700 Secondary USB Bootloader: Rev. 01 - 8 September 2009 Application Note
LPC1700 Secondary USB Bootloader: Rev. 01 - 8 September 2009 Application Note
Document information
Info Content
Abstract This application note describes how to add a custom secondary USB
bootloader to a LPC1700 series microcontroller.
NXP Semiconductors AN10866
LPC1700 USB bootloader
Revision history
Rev Date Description
Contact information
For additional information, please visit: http://www.nxp.com
For sales office addresses, please send an email to: salesaddresses@nxp.com
AN10866_1 © NXP B.V. 2009. All rights reserved.
1. Introduction
NXP’s LPC1700 microcontrollers provide the user a convenient way to update the flash
contents in the field for bug fixes or product updates. This can be achieved using the
following two methods:
• In-System Programming: In-System programming (ISP) is programming or
reprogramming the on-chip flash memory, using the boot loader software and
UART0 serial port. This can be done when the part resides in the end-user board.
• In Application Programming: In-Application (IAP) programming is performing erase
and write operation on the on-chip flash memory, as directed by the end-user
application code.
A secondary bootloader is a piece of code which allows a user application code to be
downloaded using alternative channels other than the standard UART0 used by the
primary bootloader (on-chip). The primary bootloader is the firmware that resides in a
microcontroller’s boot ROM block and is executed on power-up and resets. After the boot
ROM’s execution the secondary bootloader is executed. The secondary bootloader in
turn will then execute the end-user application.
This application note uses USB as an example for developing a secondary bootloader on
a LPC1700 series microcontroller.
2. Requirements
2.1 Hardware requirements
The secondary USB Bootloader application has been developed and tested using a:
• Keil’s MCB1700 development board
• MS Windows-based workstation with an available USB port.
2.1.1 Programming
Programming the bootloader can be done using Keil’s U-LINK JTAG module. However,
as an additional option the LPC1700’s ISP programming functionality can be used
instead. To program using the ISP protocol an RS-232 serial cable is required and a free
ISP programming tool is available from FlashMagic at:
http://www.nxp.com/redirect/flashmagictool.com/
2.1.2 Jumper settings
In order to use the USB device functionality, ensure that the USB’s D+ and D- jumpers
are both set to the “DEVICE” header pins as shown in Fig 1.
2.1.3 USB cable
A USB-A to USB-B cable is required to power and connect the windows workstation to
the MCB1700 development board.
2.1.4 Bootloader’s ISP entry mechanism
Having an entry pin grounded during reset will cause the secondary USB bootloader to
go into ISP mode. For convenience, P1.20 is used by default because it is wired to the
center button of the joy-stick as shown in Fig 1. By pressing down on the MCB1700’s
joystick during reset will cause the secondary USB bootloader to enter ISP mode.
Both the secondary USB bootloader and the user application reside in flash. Therefore,
for the secondary USB bootloader to flash the user application without modifying any of
its own code, the user application will be flashed starting with the next available sector.
Additionally, any flash sectors that do not contain any code may be used for data storage
using the IAP commands.
3.2 ISP
ISP (In-system Programming) is supported in all LPC1700 series microcontrollers. ISP
programming can be used to flash the microcontroller while it is in the end-user system.
The ISP protocol consists of commands that are sent in ASCII format via the UART0
interface.
A detailed description of the ISP commands can be found in the LPC1700 user manual.
A free 3rd-party utility is available from Flash Magic at:
http://www.nxp.com/redirect/flashmagictool.com/
3.3 IAP
IAP (In Application Programming) is a feature that allows a user application to erase and
write to on-chip flash memory. In order for the secondary bootloader to flash the user
application onto the on-chip flash it needs to utilize these IAP commands.
A detailed description of the IAP commands can be found in the LPC1700 user manual.
3.4 CRP
The LPC1700 has three levels of CRP (Code Read Protection) as shown in Table 1.
The user flash content cannot be read but can be CRP1 CRP1 ENABLE
updated. The flash memory sectors are updated
depending on the new firmware image
The user flash content cannot be read but can be CRP2 CRP2 ENABLE
updated. The entire user flash memory is erased
before writing the new firmware image.
The user flash content cannot be read or updated. CRP3 CRP3 ENABLE
The USB bootloader ignores the Entry Mechanism
(Update Entry Pin) and always executes the user
application if present. If user application is not present
then "Update" mode is entered.
CRP is used as a security feature so that the code stored in flash can’t be read using
external tools, such as JTAG. The level of access restrictions depends on the CRP level
selected.
Caution: If CRP3 is enabled, changes to the flash space can only be performed using
IAP in the user application. Assuming a valid user application is present, the secondary
USB bootloader will NOT enter ISP mode if CRP3 is selected.
4. USB communication
There are many USB Device Classes like DFU (Device Field Upgrade), HID (Human
Interface Device), and MSCD (Mass Storage Class Device). The MSCD presents easy
integration with a PC‘s operating system. This class allows the embedded system’s flash
memory space to be represented as a folder in a Windows/Linux environment, and the
user can update the flash with a binary image using drag-and-drop (e.g., using Windows
Explorer).
To make the LPC1700 appear like a folder (or disk drive), we need a FAT (File Allocation
Table). In order to fully understand how the FAT file system works, the reader is advised
to search the web for details on File Allocation Table and Storage Class Devices.
In our example code, we implemented the FAT12 system, which supports up to 32 MB
(volume size of the drive), making this useful for large embedded devices. To simplify
things, the LPC1700 on-chip code Flash will appear as one single entity (file name:
firmware.bin), solving any defragmentation problems. FAT12 is supported by Windows
9x to XP, Vista and Linux.
In this application note, we do not attempt to explain how the Mass Storage Class is
implemented. This secondary USB Bootloader code is a modification of Keil’s USB Mass
Storage Class example (http://www.nxp.com/redirect/keil.com/336.asp). The source files
for the complete project are provided for the reader to use and understand.
Since programming flash is based on a sector-by-sector basis, the code for the user
application cannot be stored in any of the same flash sectors the bootloader uses.
For efficient use of flash space, the user application should be flashed into the next
available empty sector after the bootloader. Note that the user application will also
contain its own interrupt vector table as shown in Fig 4.
5.3.1 User application execution
If the secondary USB bootloader is not going to enter ISP mode, it will start the execution
of the user application. To do so, it will issue a branch statement to the application’s
starting address, which happens to be the starting address of that particular flash sector.
By default, the secondary USB bootloader will start user code execution by issuing a
branch statement to 0x0000 2000.
5.3.2 Updating the vector table offset register
The secondary USB bootloader will change the Cortex-M3 NVIC’s Vector Offset Register
in case the user application uses interrupts.
Changing the vector table offset register will not affect the user application if it doesn’t
use interrupts. If the user application wishes to use its vector table in SRAM, it is up to
the user application to create that vector table.
See ARM’s technical reference manual on the Cortex M3 for more details.
Fig 6. USB Bootloader MSCD – CRP Disabled Fig 7. USB Bootloader MSCD – CRP1 Enabled
Opening the firmware.bin located on the MSC drive while CRP is enabled will show a file
containing only NULL values. If CRP is disabled, then the binary file will contain the
contents of the flash sector starting from the user application.
Pin 0 - 31 20
The default values shown are sufficient for the secondary USB bootloader example.
Specific USB configuration properties are outside of the scope of this Application Note.
One option of interest however might be “USB Power”. For “USB Power” there are two
possibilities: bus-powered and self-powered. The MCB1700 is bus-powered since it
derives its power from the bus. If the user’s application has its own power source, then
the self-powered option needs to be selected.
Fig 10. Flashing the secondary USB bootloader using Keil’s uVision
At this point, because the LPC1700 has no user application it automatically enters ISP
mode upon reset.
Go to the “My Computer” window and locate the newly created drive with a “CRP
DISABLE” label. If the CRP level has been changed in USB bootloader project, it will
display the new CRP level instead.
5.6.2 Flashing the user application
• Create the binary file of the user application (See Section 6).
• Enter the secondary USB bootloader’s ISP mode.
• Open the newly created drive created in the “My Computer” window.
• Delete firmware.bin
• Drag’n’Drop (or Copy and Paste) the binary file of the user application onto this drive.
• Reset the LPC1700
From here on, unless the entry pin (P1.20 by default) is grounded, the LPC1700 will boot
into the user application.
6. User application
This section briefly describes the necessary steps needed in order to make the user
application usable by the bootloader.
By design, this block of code (Fig 14) from the system_LPC17xx.s sets the user
application’s CRP level because it is intended to be used without a secondary
bootloader.
(1) This scatter file reflects the Target option changes to relocate code to sector 2 (0x2000)
As the starting address for the user application was adjusted in section 6.1.1, uVision’s
scatter file has also been updated to reflect these adjustments. However, since the CRP
code block inside the system_LPC17xx.s startup file explicitly addresses 0x02FC, the linker
detects that this portion of code is outside of the scatter file’s load region and hence
automatically creates an additional load region.
Without removing the CRP code block, the fromelf tool will output a folder containing
multiple binaries instead of a single binary file due to the multiple load regions.
a. Without the CRP code block b. With the CRP code block
The binary file referencing to “0x02FC” in Fig 16b contains the code block from the
system_LPC17xx.s startup file. By commenting out the code in Fig 14 you should only see
only one binary file as shown in Fig 16a.
When comparing the HEX (.hex) files of the user application without the CRP code with
the user application with the CRP code, the difference can be clearly observed. Fig 17
shows the two hex files side-by-side. The machine code on left has been generated
without CRP code.
The machine code on the right is the exact same code, with the exception that it includes
the CRP code located in the system_LPC17xx.s startup file. In this build, you can see that it
includes data intended to be placed at 0x02FC.
7. Conclusion
By using a secondary bootloader it is possible to conveniently perform in-application
software updates without using additional development hardware, such as JTAG. In this
case this secondary bootloader uses USB to transfer the binaries to the LPC1700, but
other channels such as Ethernet and I2C are also possible.
This application note serves as a reference on how use, create, and modify a secondary
USB bootloader. The secondary USB bootloader has been designed as a standalone
project that contains all of its dependant source files. The user applications used for this
demonstration are modified code examples that come included with Keil’s uVision
toolchain.
8. Legal information
to result in personal injury, death or severe property or environmental
8.1 Definitions damage. NXP Semiconductors accepts no liability for inclusion and/or use of
NXP Semiconductors products in such equipment or applications and
Draft — The document is a draft version only. The content is still under therefore such inclusion and/or use is for the customer’s own risk.
internal review and subject to formal approval, which may result in
modifications or additions. NXP Semiconductors does not give any Applications — Applications that are described herein for any of these
representations or warranties as to the accuracy or completeness of products are for illustrative purposes only. NXP Semiconductors makes no
information included herein and shall have no liability for the consequences representation or warranty that such applications will be suitable for the
of use of such information. specified use without further testing or modification.
Export control — This document as well as the item(s) described herein
may be subject to export control regulations. Export might require a prior
8.2 Disclaimers authorization from national authorities.
General — Information in this document is believed to be accurate and
reliable. However, NXP Semiconductors does not give any representations
or warranties, expressed or implied, as to the accuracy or completeness of
8.3 Trademarks
such information and shall have no liability for the consequences of use of Notice: All referenced brands, product names, service names and
such information. trademarks are property of their respective owners.
Right to make changes — NXP Semiconductors reserves the right to make
changes to information published in this document, including without
limitation specifications and product descriptions, at any time and without
notice. This document supersedes and replaces all information supplied prior
to the publication hereof.
Suitability for use — NXP Semiconductors products are not designed,
authorized or warranted to be suitable for use in medical, military, aircraft,
space or life support equipment, nor in applications where failure or
malfunction of a NXP Semiconductors product can reasonably be expected
9. Contents
Please be aware that important notices concerning this document and the product(s)
described herein, have been included in the section 'Legal information'.