Datasheet

I2C Bootloader
Document Number: 001-13258 Rev. *J Page 5 of 39
 The first is blocks 0 and 1 of ROM. These blocks contain critical interrupt vectors and restart vectors.
Because it is nearly impossible to control read access to these blocks by any operating device, they
are never erased and reprogrammed. The first two blocks of ROM must not be modified and cannot be
placed in any other location.
 The second memory area is the relocatable interrupt table. This table may consist of one or two blocks
depending on the architecture of the device. This area contains interrupt and general purpose vectors
to give a jump table for interrupts or code entries that may be altered when a new application is loaded
using the bootloader. For example, this area contains the application start address. The bootloader is
able to use this address to start the new application after the checksum has been validated at power
up. This area is placed at block 2 and 3. After the application and bootloader are deployed, the con-
tents in this area may be rewritten, but its location must not be modified. The characteristics of this
area are similar to the checksum area described in the next section.
 The third area of ROM defined is the checksum area. This area is placed at block 4 and it contains
important data that the bootloader software uses to download and verify the foreground application.
The checksum area contains the start address and size in blocks of the foreground application. The
first two bytes of the checksum block are a checksum of the checksum block itself. The last two bytes
are the checksum of the runtime application. The structure of the checksum block contains space for
you to define your own data in addition to that used by the bootloader. This structure is exposed as a
C-structure definition and may be modified as long as data used by the bootloader utility is not
changed or repositioned within the block.
 The fourth area of memory to be defined is the area containing the bootloader code itself. This area is
started at block 5. After the project or device containing the bootloader is deployed, this area is not
reprogrammable and cannot be field upgraded.
 The fifth area is reserved for customer's data. This may contain configuration data that must persist
through an upgrade using bootload. As shown in the memory map, this area is optional. You can use
the Standard Memory Map if there is no custom data.
 The sixth memory area is the application area. This area holds the application image. Because the
code size of the "Bootloader Code" area is expandable, the starting address of this area is adjustable.
The "Appliaction_Start_Block" parameter (in properties window) allows users to set the application
starting address accordingly. This area should occupy all remaining memory.
If your application has code that must always be operational, including during a bootload process, the
design of the BootLdrI2C User Module can allow sufficient customization to accommodate this. The best
way to accomplish this is to add this code to the bootloader ROM area using the assembler AREA
directive. Any RAM used by your code during the bootload process needs to be added to the RAM area
defined for the bootloader.
Definition of Memory Areas in the User Module Parameters
The BootLdrI2C User Module parameters enable you to customize where major program elements are
placed in ROM. The defaults in the user module should give a working initial setup. Use these settings
until a complete project is successfully compiled. After you have a compiled project, you can see the
program memory map and .hex output file to determine how to optimize your program structure. If you
reconfigure the parameters and accidentally create memory area conflicts, it may be difficult to determine
the correct locations without a valid memory map to look at.
Bootloader Utility
The BootLdrI2C User Module gives a complete utility that coexists with a foreground (primary) application.
When the device is started or reset, the bootloader utility is always invoked. Once invoked at system
startup, the bootloader validates the foreground application by calculating a checksum on the foreground
application ROM area. The calculated checksum is compared to the one stored in the checksum block