Datasheet

I2C Bootloader
Document Number: 001-13258 Rev. *J Page 16 of 39
from a watch dog timer reset condition, it is possible to monitor a status bit associated with the watch-
dog timer to detect that this is the cause of the reset condition (see the Technical Reference Manual).
5. Two projects have been developed and the bootloader in each is different in some subtle way. Remem-
ber that bootloading implies that programming part of a device is taking place. This implies that the
implementation of the bootloader for each of two mutually reprogrammable applications must be iden-
tical. All bootloader parameters and relocatable code start addresses must be identical (that is, differ-
ent from first application block). Debug strategies for this problem include comparison of the two hex
files in question, paying particular attention to the areas of hex code used by the bootloader. Another
method is to compare the <project>.lst files. The bootloader uses some redirect vectors to allow cer-
tain application address parameters to change. All these jump vectors must match for an application
and a bootloader. After a bootloader is deployed to a field application, there is no way to alter the code
within it. A future application must still ‘agree’ about where mutually used jump vectors are stored.
6. The PSoC based translator app hangs when a bootload operation fails. There is an if-def based time-
out that can be configured to allow the PSoC base translator to drop a communication attempt after a
variable software loop. For debugging purposes, you can turn this software switch on or off. Examine
the source code of the project for the timeout switch.
7. Power Stability. Power noise, glitching, brownout, slow power ramp poor connections. All of these
power problems can cause difficult to diagnose problems with flash programming. Program execution
is rapid with respect 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 opera-
tions. Poor power stability may contribute to non functional parts and may appear to be the result of
poor flash retention.
Application Programming Interface
The Application Programming Interface (API) firmware gives high level commands that support sending
and receiving multi-byte transfers. Read buffers may be set up in RAM or Flash memory. Write buffers can
only be set up in the RAM memory.
Note
In this, as in all user module APIs, the values of the A and X register may be altered by calling an API
function. It is the responsibility of the calling function to preserve the values of A and X before the call if
those values are required after the call. This “registers are volatile" policy was selected for efficiency
reasons and has been in force since version 1.0 of PSoC Designer. The C compiler automatically takes
care of this requirement. Assembly language programmers must ensure their code observes the policy,
too. Though some user module API function may leave A and X unchanged, there is no guarantee they
may do so in the future.
For Large Memory Model devices, it is also the caller's responsibility to preserve any value in the
CUR_PP, IDX_PP, MVR_PP, and MVW_PP registers. Even though some of these registers may not be
modified now, there is no guarantee that will remain the case in future releases.