LPC1300 In-System Programming (ISP) via USB

1 Introduction

 

    The LPC1300 series of microcontrollers based on the ARM  Cortex-M3  CPU architecture feature high-level block integration support and low power consumption in embedded applications. LPC1300 auxiliary peripherals include up to 32KB of flash memory, 8KB of data memory, USB interface, 1 UART, 1 SSP controller, SPI interface, I2C interface, 8-channel 10-bit ADC, 4 general-purpose timers/PWMs, and up to 40 general-purpose I/O pins.

  

In addition, the on-chip ROM (a bootloader) that can be programmed in-system  supports UART and USB  flash programming, similar to the user code programming method of APIs.  The flash API implements the on-board flash programming function through a simple interface and can enter ISP mode at any time.  The USB API is compatible with new products of human interface devices (HID) and mass storage devices (MSC), and does not require users to write drivers or store them in flash.

 

The items included in this manual are as follows

1. Overview of USB Online System Programming

2. USB  ISP  details

3. Automated  USB  ISP

4.  Automatic entry of USB ISP

5. Software Examples

6 Conclusion

 

2. USB  In-System  Programming (ISP)  Overview

    

    The LPC1300 has on-chip USB  ISP firmware that can be programmed and updated by the end user through a standard PC operating system. This document references a portion of the LPC1343 content, and similar treatment is also applied to other LPC1300 series products that also have on-chip USB.

    Keeping PIO0_1 low during power-up will cause the on-chip ISP firmware to enter ISP mode (unless prohibited by the NO_ISP Code Read Protect [CRP] mode). Once in ISP mode,  the PIO0_3 port on the USB VBUS will be checked for level. If it is high, it will enter USB  ISP; if it is low, it will enter UART  ISP. In the section titled "Boot Process  Flowchart" in the User Guide manual  , there is a chart that describes this process in detail.

    After entering USB  ISP mode, the LPC1300 can use the on-chip full-speed USB interface as a mass storage device. This disk device contains a FAT12 file system, which is a standard disk device for most operating systems. The drive letter will indicate the CRP status and the disk will contain a single file, firmware.bin. Deleting and rewriting this file will write to the flash memory if the code protection settings allow it. Reading the contents of the flash memory is as simple as copying the firmware.bin file.

 

 

 

 

 

 

 

Figure 1    LPC  1300  USB  ISP  system

 

 

 

Figure 2  USB ISP  firmware.bin file on    Windows  XP

 

 

 

 

 

 

 

 

3.   USB  ISP  Detailed Description

 

      LPC1300 on-chip USB  ISP firmware, virtual FAT file system, so that the firmware can be read and written by PC software. We describe in detail the simulation process and techniques for updating the firmware on several standard mainstream operating systems.

    After the LPC1300 connects to the USB host and initializes USB  ISP mode, it enumerates the USB vendor ID  0x04CC and device ID  0x0003. This information is usually hidden from the end user, but through the firmware update software, this information can be used to find USB devices that have LPC1300s connected to the computer. Once these devices are found, a storage device query command is sent, and a string of attachments describing the LPC microcontroller product is returned. The query string for LPC134X products is "NXP  LPC134X  IFLASH  1.0". These devices can also be identified by the device manufacturer name "NXP" and the device model "LPC134X  IFLASH". In this way, the full name of the device model ID is "NXP_LPC13XX_IFLASH".

[page]

    The disks emulated by the LPC1300 have different volume labels, which depend on the Code Read Protection (CRP) setting and on minor changes during reprogramming. These are briefly described below, but the full documentation is in section UM10375 of the LPC1300 User Manual.

    If CRP1 or CRP2 is available, the user flash will be erased when a file is deleted or a new file is copied, causing the original file to change.

    If CRP1 is available, or if neither CRP is used, the user flash will be erased or reprogrammed (when copying the new file). Even then, only the area covered by the new file will be erased or reprogrammed. Therefore, ideally the new programming file will contain the entire flash capacity (32KB for LPC1300), so that the entire flash capacity is in a known state. Using a padded (32KB or flash size) programming file also allows error checking of the connected LPC part by the programming tool (compare the size of the new firmware file with the firmware.bin file on the device), without the need for additional configuration information.

 

Note: Only Windows commands support copying and deleting the LPC1300  flash  image folder. If the virtual disk space is insufficient to store the temporary files created by Windows during the overwrite process, the overwrite operation will not succeed using Windows Explorer.

 

 

Figure  3   LPC1300 User Manual - CRP Disk Volume Label

 

 

 

The boot disk virtual FAT file system consists of a single file firmware.bin, which contains information about the entire flash capacity. Usually, the capacity of a disk must be slightly larger than the required storage capacity, depending on the directory and top-level file system allocation table. Under the LPC1300 virtual FAT file system, 4 additional blocks are required to provide for the boot block, root directory, and file allocation table. Because the MCU needs to use ISP to program the entire flash memory, these additional blocks are simulated using data from RAM and ROM, rather than being mapped to flash for code storage. Therefore, the file system metadata will be lost when power is lost, and only data programmed into flash via file writes will be saved.

    On flash, data written to the file system is stored in disk block order, starting at block 4. If the firmware.bin file is deleted, the PC will allocate any new file starting at block 4 when running Windows, and use more blocks as more data is written. This means that in Windows, the firmware can be written to the LPC1300 using any standard program or tool. In the Windows Explorer window, the user can delete the firmware.bin file and drag a new file to program the flash. Unfortunately, the FAT file system on Mac and Linux machines allocates blocks in a different order, with data written to the ISP disk and firmware written to flash, rearranging. This will result in an unsuccessful firmware update. There are two workarounds for this. The most common method is to overwrite the firmware.bin file appropriately, and the other more violent method is to gain administrative privileges and directly write to the disk device /dev.

 

 

 

 

 

 

4. Automated  USB  ISP

 

    Sometimes, it is desirable for the system to perform a firmware update without user intervention. It is often complex to require the user to determine which disk drive is connected to the USB device, or to require them to manually delete and rewrite a file. Often, the firmware needs to be updated automatically under the control of a computer program. This section will describe how this is accomplished. In order to run fully automatically on the computer, the program needs to find the correct USB device to update, change the USB device "handle" to a file path, check the CRP mode, burn the saved file to flash, and finally unmount the disk drive to ensure that the flash contents are preserved. These steps are discussed separately. This can effectively verify that the firmware file is burned.  This can be verified  using the "Criterion for  Valid  User  Code" in the LPC134X User Manual, which has been performed using the Windows ISP tool. It also verifies that the device space being burned is the same length. This is an example of ISP applied on  a Mac  and  Linux  system. Note: Some deviations in these steps will not be significant in simple implementations on different operating systems.

 

 

 

 

4.1  Find the correct USB device

 

     The method for enumerating USB devices depends on the operating system. On Linux, most distributions provide a program called lsusb that can search for  USB  devices with a specified vendor ID and product ID. Then, udevadm (on current systems using the udev device file system) can list the USB  model ID and the system device path. The model ID for the LPC1300 series is "NXP_LPC13XX_IFLASH". Once the vendor ID, product ID and model ID are confirmed, you will definitely find an NXP  LPC1300 microcontroller in ISP mode. In Windows and Mac  OS-X, the steps are a bit different. On Mac, the USB device model information can be obtained from the disk database, so there is no need to find the actual USB device. Instead, the disk device is not detected until the correct manufacturer and device model are found. Under Windows, there is a similar process to  retrieve the disk information through iTuner UsbManager. 

 

 

 

4.2  Change USB device control to file path

 

    In Linux, control of a USB device can be converted to a file path by iterating through all disk devices in the udev file system and querying udevadm for their system device paths until a USB device with ISP is found.

 

1. lsusb names the device with the manufacturer ID and the NXP  ISP device product ID. lsusb outputs the bus and device IDs to standard  out (console). The output is used to create a udev path for the USB device, for example, the path for bus 2 device 3 is /dev/bus/usb/002/003.

2. A disk device name  is extracted from /dev. In our sample script, we use a wildcard that matches /dev/sd[az] and loop through the devices that match combinations like /dev/sda, /dev/  sdb,  /dev/sdc, etc. This will find disk drives on the system, including hard disks and USB mass storage devices.

3. Use udevadm  info  -q  path  –n  /dev/sdX  to find the complete low-level disk device file path  . If the disk device is related to the USB device we found, the returned file path starts with the low-level USB device file path.  

4. Finally, the output of the mount command is used to determine where in the Linux file system the disk device name tested in step 2 is mounted. We now have a file system path for our USB  ISP device and can access  firmware.bin 

 

On  Mac  and  Windows  systems, we use  disk operations  (instead of USB device operations) and query the drive letter and file path of the operating system

 

4.3  Check Code Read Protection (CRP)

    The LPC1300  USB  ISP features a feature that sets the USB drive letter to indicate CRP mode.  The USB ISP  flash programmer is designed to check the drive letter to make sure CRP is not enabled. Under Linux, the file system letter for FAT drives can be  read using the mtools package. Unfortunately, this is not recommended as it requires administrative access. Another way to read the file system letter under Linux is to use  the mount  -l  command if your system's version of mount supports it. This will list all mounted file systems and their drive letters. Under  Mac  and  Windows  operating systems, the drive letter information is displayed in the DiskDescription directory or retrieved from the WMI  respective target in the Volume  .

If CRP1 or CRP2 is enabled,  the firmware.bin  file in the USB ISP  disk  must be deleted to disable code protection before new files can be written. After deleting  firmware.bin  , the device needs to be powered off and reconnected for the changed CRP settings to take effect so that the firmware can be updated. If CRP3 is enabled, the device cannot be erased and the firmware cannot be updated.

 

 

4.4 Write files to program flash

Under Windows, almost any standard file system write sequence works this way, Windows variants of FAT file systems allocate blocks starting with the first free block on the ISP disk. Under Linux, the device itself can be written directly (using /dev), but dd must be used at the same time to confirm the block sequence. This method is not recommended, as it requires the user to have  administrative   privileges. A second option is to open  the existing  firmware.bin  on the USB ISP disk and overwrite the contents. If the file is opened without truncation, the new data will be written with the same rules as the existing file (the one created by the ISP firmware). (Remember that "file  metadata"  is created by the ROM code and is not stored to flash) Overwriting can be achieved by using dd to write the firmware.bin file with the options conv=nocreat,notrunc. If the code is written in C, use  open(path,  O_RDWR)  or  fopen(path,  "r+") whenever possible. Also, under Windows, there is no need to overwrite existing files, so if there is storage space available, just overwrite or delete the current file to free up storage space. In the Windows program example we provided, we used the C#  function System.IO.File.WriteAllBytes(filePath,  firmwareData) and simplified it before writing.

 

4.5  Uninstall disk device

Most operating systems will eventually write the entire device to disk after a delay, but a forced unmount is a valid last step to ensure that the operating system completes the write operation so that the user is notified when the device has been successfully removed. For the unmount operation to succeed, all open files including the firmware.bin  file must be closed first. In Linux operating systems  , the posix (portable value interface) standard  umount  command can be used. Generally, administrative privileges are not required to unmount an automatically mounted USB mass storage device. In Mac operating systems, because the disk arbitrator can automatically manage the mount operation, using the DADiskUnmount system call is the best path. In Windows operating systems, most users use self-unmount or use the  CM_Request_Device_Eject function in the SetupAPI. In our example, the Windows  ISP  Updater does not unmount the device when it does, instead, it displays a dialog box to notify the user.

      

  Figure 4[page]

5. Automatically enter USB  ISP

 

    In the previous section, we explained  the process of updating device firmware from a PC in USB ISP mode. The NXP  LPC1300 microcontroller defaults to ISP mode when the firmware is not programmed or when a pin is pulled low (PIO0.1 in the LPC134x series) and the device is reset/powered up. Sometimes, users do not want to press a button to update the firmware and connect the device in ISP mode. In this case, we can design firmware that allows programming in ISP mode.

    Programming in ISP mode is possible in the LPC1300 on-chip ROM through In-Application  Programming  API requests. After the firmware is updated, the user needs to reboot the device for the new firmware to take effect. After downloading the new firmware, the new firmware can pre-set the watchdog timer to reset the LPC1300. The following flowchart shows the device's automated ISP process. The software example named "autoisp" demonstrates this technique. 

                                                                                                     

                          

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 Figure 5

 

 

 

6 Software Examples

 

 

To establish a user-friendly firmware update tool as early as possible, NXP has released three examples (an ISP downloader and source code). A C#-based application form is provided, which runs on Windows  XP, Windows  Vista and Windows  7.  The Windows application can be extended using Microsoft  Visual  Studio  C#  Express  2010. A command-line tool written in C is available for use on Mac. This tool  has been enhanced in Apple Xcode and can run on OS-X  10.5 or higher. Finally,  there is also a scripted script for Ubuntu Linux, which has been  tested on Ubuntu 10.04 and can run on different versions of Linux with the same udev file system and tools.

    All tools are open, unrestricted and reusable, except the Windows application [which depends on  the USB disk device class of the iTuner (http://ituner.codeplex.com/) project]. This is a derivative work under an open source license requiring the source code to be made available.

    The application note also includes a blinky program that implements code read protection. This program is used in the  LPCXpresso  IDE  to blink an LED on the LPCXpresso board and count the 7-segment display on the embedded board. There are nine compiled versions of the program, so the device can be programmed repeatedly (with different CRP modes and LED blink/count rates).                  There is also a program called "autoisp". This example shows how to enter ISP mode under program control. After blinking the LED for ten seconds, ISP mode is entered. If the device is connected to a PC, it will sequence the outputs and the firmware will start flashing. During this time, the LPC1343 enters ISP mode and the watchdog timer continues to run. After the time is up, the LPC1343 resets and runs the firmware again.

Finally, there is a small command line program called "padto". This program is used to take the binary output from the development tool and pad it with 0xFF bytes until it matches the size of the flash on the LPC. This matching helps the ISP downloader on the host PC to ensure that the firmware is appropriate for the specific LPC134X connected to the USB.

Windows  NXPISP  Utility 

    This program is based on Microsoft  .NET  . When the setup.exe  program is run and started, the included Visual  Studio  Installer  will check the computer and download  the latest version of  NET  (if it is not installed yet). Therefore, when you run the setup.exe program for the first time, please make sure you are connected to the Internet via broadband. After the Windows  .NET subsystem is updated, the NXPISP program will be automatically installed and run. When NXPISP is running, click "Select  Firmware." A file selection dialog box will pop up and let you select a .bin file. This .bin file will be checked with "Criterion  for  Valid  User  Code", that is, the sum of the first 8 32-bit words of the vector table is 0. If  the bin  file meets the requirements, the green check mark of the "Select  Firmware"  button will show correct, otherwise. A red X will be displayed.

    To actually flash a device, click  "Update  Firmware."  The "Update  Firmware."  button works like a trigger and can stay depressed when clicked or released by clicking it again. While the button is pressed, the computer will scan for NXP  ISP devices. If one is found, its firmware will be updated and the green check mark of the "Update  Firmware"  button will show right and the button will be released. If no device is found, the "Update  Firmware" button will stay depressed and the tool will wait for a device to be connected. After the device is found and updated, the green check mark will show and the "Update Firmware  "  button will pop up. If the utility is waiting for a device to connect (the "Update  Firmware"  button is still depressed) it will be cancelled and caused to pop up by clicking the "Update Firmware"  button again  .

    Safely eject the USB  ISP device to ensure the new firmware is written (the Windows  NXPISP tool will not unmount the device). Safely eject the device via the Windows Hardware Eject icon and the Windows Explorer Eject option. Failure to do this will result in corrupted firmware.