Datasheet

I2C Bootloader
Document Number: 001-13258 Rev. *J Page 15 of 39
For development and debugging purposes, a flash security of 'U' (unprotected) is recommended for the
application area. For final production, a flash security setting of 'R' (read protected) is recommended on
the application area to prevent external reads and writes from occurring.
Incorrect Relocatable Code Start Address (Linker Parameter ImageCraft Compiler Only)
The memory map for a bootloader project is considerably different than that for a conventional project. As
a result, the relocatable code start address usually needs to be altered. This is a common source of the
errors generated by the linker when it attempts to write more than one block code to the same address.
This parameter can be changed in the Relocate code start address filed in the Project > Settings > Linker
tab. Calculate the absolute hex start address as a little more than the highest block used by the bootloader
code, or to occupy an unused area of ROM. For the I
2
C version of the bootloader setting, this value to
0xA40 should be adequate (if the default values of the other parameters are used).
Note When unplacing the BootLdrI2C User Module, the Relocatable Code Start Address does not reset
to its original value. You must change it back manually to save ROM space.
Memory Overlap
To correct the relocatable code start address (see previous section), use a leading semicolon to comment
out the last three lines of the custom.lkp file, attempt to build the file again, and examine the resulting
memory map. Memory overlap problems are difficult to diagnose, because they prevent output files from
being generated. Modifying the custom.lkp file may allow the linker to place object blocks, which then
gives a starting point to correct the memory overlap root cause.
Power Stability
Power noise, glitches, brownout, slow power ramp, and poor connections can cause difficult to diagnose
problems with flash programming. Program execution is rapid in comparison to power ramps, and in some
cases, a part may still have changing power levels when flash programming takes place. One example is
a status write to flash at power up. You must evaluate your use model and the potential for changing
power supply conditions during flash operations. Poor power stability may contribute to nonfunctional parts
and may cause poor flash retention.
Downloading a New File Causes the Device to Stop Working
It is possible to unintentionally construct applications with no facility to enter the bootloader utility. For
example, a main{} function with a simple while(1); loop never returns and never enters the bootloader. As
a result, it cannot be reprogrammed after it begins executing (as long as it has a correct checksum). There
are multiple strategies to address this problem. No default method is included in this user module. A few
suggestions are:
1. Apply a reset condition that allows a period of time when the bootloader is enabled when the device
first powers up. By setting timeout parameters, the device could be configured to enter the bootloader
upon reset, and exit to the foreground application when the timeout expires.
2. Set a test at some point in the code that causes the device to enter the bootloader. This could be switch
closure or holding a port pin low/high.
3. Enable the I
2
C application resource and create an I
2
C command that causes the device to
enter the bootloader. Generally, if I
2
C is enabled by the main routine, the bootloader address can
be used to cause the device to enter the bootloader.
4. Use the Watch Dog Timer to reset the device if it is not serviced regularly. This could be combined with
one of the previous strategies to allow a WDT interrupt to initiate a bootloadable state. When reset