NXP ARM Vector Table CheckSum

Signature Creator for NXP Cortex-M Devices

Algorithm for creating the checksum

The reserved Cortex-M3 exception vector location 7 (offset 0x001C in the vector table)

should contain the 2’s complement of the check-sum of table entries 0 through 6.

This causes the checksum of the first 8 table entries to be 0.

The boot loader code checksums the first 8 locations in sector 0 of the flash.

If the result is 0, then execution control is transferred to the user code.

Application integrity check

Following a reset the secondary bootloader checks if there is a valid image contained

within the application flash sectors.

It does this by generating a 16-bit CRC of the application flash sectors

and comparing it to the value stored in the last 2 bytes of flash memory.

If the two values match then the secondary bootloader executes the application,

if not the process of downloading a new application is started.

NXP LPC parts use a word in the vector table of the processor to store a checksum

that is examined by the bootloader to identify a valid image.

For ARM7/ARM9 based parts this checksum word is stored at offset 0x14,

for Cortex-M based parts it is stored at offset 0x1C

Note: 

This checksum is calculated from the contents of the vector table, not the whole image.

For more details please see the user manual for the MCU that you are using.

When downloading code via the debugger, this checksum word

will be filled in automatically as the image is downloaded.

When creating a binary file, you will need to ensure that you run the supplied checksum utility

to post-process the binary yourself.

If you modify the supplied post-build step to create your binary

(as per the FAQ Post-processing your linked application,

then this will normally be done automatically by the post-build step:

checksum -p ${TargetChip} -d ${BuildArtifactFileBaseName}.bin;  

But if you need to create a hex file for use by FlashMagic care needs to be taken

that you do not run the checksum utility on the hex file itself.

The checksum utility only works on binary files, not hex files.

Therefore, the checksum utilty will corrupt your hex file if you use the hex file as input.

Note that FlashMagic will automatically set the checksum word for you

when you use it to program a hex file to an LPC device.

But if you wish to set the checksum yourself, then the recommend way of creating such a hex file is as follows:

• convert to binary

• run the checkum utility

• convert the binary in hex, using 
  arm-none-eabi-objcopy -I binary -O ihex myfile.bin myfile.hex

Generating other types of checksum

There are many other different types of checksums that users may want to perform on an image.

A great tool for manipulating image files and generating a variety of checksums is the Open Source SRecord Tool.

ARM: LPC18xx/43xx

On-chip Flash Loader Vector Checksum Calculation

Information in this knowledgebase article applies to:

• MDK-ARM
• LPC18xx/43xx On-chip Flash Loader

SYMPTOM

When I load an example to the internal flash on the LPC18xx/43xx and correctly set the boot pins, the program still won't run.

What could be wrong?

CAUSE

The most likely reason this happens is that the application does not fulfill the criterion for Valid User Code.

Unlike the on-chip flash loaders for other LPC devices, the flash loader for LPC18xx/43xx on-chip flash

does not calculate the NXP specific vector table checksum.

So the on-chip boot loader will not detect valid user code and does not boot from it.

The reason for this different behavior is that LPC18xx/43xx

can boot from different flash banks.

It is up to the user to place the vector table in flash bank A or B.

The generic flash loader must NOT modify the flash bank which does not contain the vector table.

RESOLUTION

Add the checksum to the output file with a user command that runs automatically after the build.

MDK-ARM also supplies the suitable command line tool for this purpose.

In Options for Target — User — Run User Programs After Build/Rebuild add:

$KARMBINELFDWT.EXE !L BASEADDRESS(0x1A000000)

If your application starts from bank A.
Or add:

$KARMBINELFDWT.EXE !L BASEADDRESS(0x1B000000)

if your application starts from bank B.

So the correct vector checksum will be added to the output file

and the NXP on-chip boot loader will recognize it as valid user code.

#include <stdio.h>
#include <stdint.h>

#define BLOCK_COUNT 7
#define BLOCK_LENGTH 4
#define BLOCK_TOTAL (BLOCK_COUNT*BLOCK_LENGTH)

typedef unsigned char byte_t;

int main(int argc, char *argv[])
{
  FILE* pf;
  byte_t buf[BLOCK_TOTAL];
  uint32_t crc = 0;
  uint32_t block;
  
  // Check for required arguments
  if (argc < 2)
  {
    printf("syntax: lpcrc <firmware.bin>
");
    return 1;
  }
  
  // Try to open the supplied firmware
  if ((pf = fopen(argv[1],"rb+")) == NULL)
  {
    printf("error: could not open file [%s] with write access
",argv[1]);
    return 1;
  }

  // Read out the data blocks used for crc calculation
  if (fread(buf,1,BLOCK_TOTAL,pf) != BLOCK_TOTAL)
  {
    printf("error: could not read required bytes
");
    fclose(pf);
    return 1;
  }

  // Compute the crc value
  for (block=0; block<BLOCK_COUNT; block++)
  {
    crc += *((uint32_t*)(buf+(block*BLOCK_LENGTH)));
  }
  crc = (~crc) + 1;
  
  // Reposition the file stream indicator to switch between read and write
  if (fseek(pf,0,SEEK_CUR) != 0)
  {
    printf("error: could not switch from read to write mode
");
    fclose(pf);
    return 1;
  }
  
  // Write the crc back to the file
  if (fwrite((byte_t*)&crc,1,BLOCK_LENGTH,pf) != BLOCK_LENGTH)
  {
    printf("error: could not write crc back to file
");
    fclose(pf);
    return 1;
  }

  printf("succesfully updated crc to: %08x
",crc);
  fclose(pf);
  
  return 0;
}