Datasheet
I2C Bootloader
Document Number: 001-13258 Rev. *J Page 14 of 39
Common Problems
Updating Bootloader Projects, Service Pack Upgrades, and Compilers
Avoid changes to the PSoC Developer environment when using a bootloader application. This includes
not updating PSoC Designer, not updating the BootLdrI2C User Module, and not changing the compiler.
The reason behind this is that initially the bootloader and application are compiled together, but after a
bootloadable system is deployed, only the application section is reprogrammed. A new or revised
application must be compiled with the identical version of the BootLdrI2C User Module, so that the new
application matches the bootloader from the original deployment. Ideally, all versions of the elements in
the development environment are compatible. However, in the case of a bootloader, it is essential to
maintain that compatibility. By not changing the development environment compatibility, risks can be
eliminated.
Although multiple compilers are supported by PSoC Designer, a bootloader compiled under one compiler
may not be compatible with an application compiled under another. Also, the implementation of RAM
paging may differ from one compiler to the other. Another difficulty is that, because a bootloader and
application are compiled together, it is not possible debug a bootloader/application pair that had
mismatches in the development tools used.
RAM Allocation Problems With the HI-TECH Compiler
Some user modules use the memory in large arrays or use a large amount of RAM on page 0.
The default location for user module memory is page 0.
The bootloader demands memory at the lowest locations of page 0.
The default for HI-TECH local variables and for InterruptRAM is page 0.
With these items competing for space on RAM page 0, it is possible to run out of memory on page 0. If this
is a problem, select Project -> Settings -> Compiler, and add a line to the Options box for HI-TECH:
--AUTOBANK=1
This option moves automatic C variables to memory page 1. You can choose any memory page up to the
maximum available for the device in use. See the HI-TECH manual for further information about the --
AUTOBANK option.
Internal Use of the Watch Dog Timer
Coordination with the watchdog timer is linked to the global parameter: WATCHDOG_ENABLE contained
in the file globalparams.inc. If the project uses a watchdog timer, conditionally compiled code linked to the
global parameter automatically sets the watchdog during bootload checksum and download operations.
The CPU clock speed effects how fast the watchdog timer is updated. A practical minimum setting for the
watchdog timer is about 0.125s.
Improper Settings in Flashsecurity.txt
The default settings for this file are set when the project is created. An example configuration is given in
the file “Flashsecurity.example". Flashsecurity.example is given with the BootLoader Tools - Get Files user
module menu item. The map must allow flash write at all the locations that are eventually bootloaded. One
strategy is to make all blocks writeable. Another is to take a moment to layout your memory map now and
edit this file accordingly. No matter which strategy is chosen, taking action at the beginning of the project is
quicker than debugging it later. You must write-protect the areas of code used by the bootloader
executable. Failure to correctly map flash security can be a contributing factor in a broken system and an
extremely difficult debug task.