Datasheet

I2C Bootloader
Document Number: 001-13258 Rev. *J Page 8 of 39
allows the linker to place code automatically and can be helpful in determining application code size
requirements.
HTLinkOpts.lkp – When source generation takes place, the HTLinkOpts.lkp file is populated with
autogenerated ROM areas for major code blocks as defined in the user module parameters. Do not modify
the code blocks in the HTLinkOpts.lkp file:
 -L-ACODE... & -L-AROM... Lines contain data giving the overall ROM size.
 -L-PPD_startup... contains linker directives to locate bootloader specific ROM areas
 -L-P
 -L-Pbss0= Changes to any of the last several lines result in an error dialog indicating the inability of the
project to detect the correct HTLinkOpts.lkp file.
During code generation, several of the last lines of the HTLinkOpts.lkp file are rewritten under the control
of the code generation software. Changes made within or below the last three lines either cause an error
or are simply lost.
Flashsecurity.example – This is a default file that is laid out according to the default memory map specified
by the default user module parameters. To create the final project, you may have to manually modify this
file according the final memory map and application size for the deployed device and firmware. This is not
the file that is directly used by PSoC Designer. If for some reason the project is updated or tagged for out
of data files, it is inconvenient to have the flashsecurity file overwritten. This would then require repeated
modification by the developer. The given file flashsecurity.example may be edited and renamed as
necessary.
Flashsecurity.txt – This is a default file given by PSoC Designer. The data in this file is added to the .hex
file and instructs the device how to manage access to the internal ROM memory. If memory blocks are
protected in from Write access, the bootloader does not work. Because read and write protection is built
into the programmed PSoC, this file must be correctly configured before the first deployment of the
bootloader.
I
2
C Interrupt Processing
The standard BootLdrI2C User Module optionally gives a foreground copy of the I
2
C interrupt processing
module. This code is placed in upgradable memory along with APIs to operate a fully featured I
2
C slave.
The bootloader itself maintains an internal utility that processes I
2
C data that is addressed to the
bootloader. This is to overcome the problem of executing code that is being rewritten (this is not a good
programming practice).
Block Entry of Parameters
All memory parameters are entered in the bootloader in Blocks numbered from 0x00 through 0xFF for 16K
devices, 0x00 through 0x7F for 8K devices and 0x00 through 0x1FF for 32K devices. Although this is not
the most convenient format to enter memory addressees, it prevents accidental assignment of partial
block addresses to different sections of the memory map. The PSoC devices in question are only capable
of storing 64 byte flash blocks (128 byte for some device families), and this is a simple way to correctly
maintain the boundaries between different sections of the project code.
Most PSoC parts have 64 byte block sizes. Some new PSoC devices have 128 byte blocks. Two key facts
are:
1. Any Bootloader must write to Flash.
2. PSoC can only write to flash “Block" by “Block.
So for bootloader applications, it is more useful to think of memory as a group of “Blocks" to be written.