ISP Programming

Tags:

  3 minute read  

Analog scope pulse

Intro

Most microcontrollers these days come with integrated, ROM based, bootloader known as In-System Programming (ISP). You hookup to some default port, follow the protocol described in the docs and you can write/read the flash, query chip information, etc. The port is typically a UART but USB, I2C, and SPI are not unknown. NXP chips will enter the ISP handler if the user code is “not valid” (more on that later) or if the ISP pin is pulled down on reset.

Why Its Useful

One of the benefits to using the ISP is being able to reprogram the device with the same serial port that’s being used for serial control. This can be done with a secondary bootloader but using the built in one keeps the thing significantly simpler. The system is then exposed to reprogramming by a third party who wouldn’t need any information except the chips user manual, so that could be a security concern.

Our projects usually don’t have the volumes to warrant the cost of a bed of nails test jig so being able to program and control the device through the same port makes production simpler and faster. FTDI chips connected to the default ISP UART with a micro USB connector is a favorite configuration for small serial controlled devices. The USB can supply power to the MCU while programming so even blank devices can be programmed directly through the USB with no additional hardware. The board can be dropped into a test jig with a power connection and the serial connection can be used to fully automated programming and functional test. This is also a good time to program any code read protection, OTP, or other special registers.

How It Works

Disclaimer: I’ve only been doing this with NXP chips but STMicro and Atmel have similar systems.

So the chip starts up, checks the checksum at some location to determine if the code is valid, if the checksum is valid then it starts the application, otherwise it starts the ISP handler. An important point is that ALL that’s checked is the checksum. An image that is completely corrupted except for the first 7 words (on newer NXP chips) will boot into the corrupted application and be bricked. If the checksum is not cleared during programming and the programming fails or is interrupted your device is bricked. As you probably have physical access to the device with this method that might not be all that bad but it’s at least a pain, possibly catastrophic, and definitely not something you want.

The exact sequence and protocol are usually in the chip families user manual but the steps are essentially identical. When programming a packet is sent and stored to specific location in RAM. The CRC should be check to ensure validity and then a flash write command is sent specifying the starting location in flash to write to, the location in RAM to read from, and the number of sectors or pages.

Existing Library Tools

NXP

All of these except Flash Magic are open source. Unfortunately some of the chip families (LPC84x and LPC80x) I needed were not supported by any of the open source tools. lpctools uses a convenient configuration file format which worked. After some experimentation I found it to be not as robust as I needed, with programming failures occurring occasionally. I also wanted a python library that could be incorporated into client control software. The resulting library uses the same configuration file format as lpctools and is available on github at https://github.com/snhobbs/NXPISP and pypi as https://pypi.org/project/ISPProgrammer/.