2.4 Potential Causes of Failure

Situations where the execution of Hexmate might fail, or where the generated HEX file might lead to runtime failure are indicated in this section. This is typically the result of incorrect configuration of project code, or incorrect compiler or Hexmate options.

The following are typical causes of the data overwrite error, (944) data conflict at address *h between * and *, which indicates that more than one record holds data for the same address.

  • When writing bootloader/application projects, the configuration words have been specified differently in the application and bootloader projects. Typically, you should specify them in only one project.
  • When writing bootloader/application projects, program memory has not been partitioned between the two projects during compilation. Use a compiler option to ensure that the memory used by one project is not used by the other.
  • When writing bootloader/application projects, one project defines functions at an absolute address (using __at() or address attribute) that is within the range of program memory used by the other project. Choose different addresses or avoid using absolute functions.
  • When writing XC32 bootloader/application projects, the debug exception handler has not been discarded from the linker scripts, for example, using the following:
    SECTION
{
  /DISCARD/ : { *(._debug_exception) }
}
  • A hash, serial number, or string has been embedded at a location used by executable code or other data. Choose a different location.
  • A Hexmate-generated hash value has been stored into a region of memory used to calculate the hash itself. For example, a hash calculated over the data between addresses 0-0xFF is stored at location 0x7E. Either change the range of values used to generate the hash, or move the hash result to a new location.
The following are common reasons why hash values (such as checksums, SHAs, etc.) generated by Hexmate do not agree with hashes calculated at runtime.
  • The byte order of data within words is processed in different orders, for example, MSB first versus LSB first. Change the algorithm in your code, or specify a revWidth value in the -CK Hexmate option.
  • Unused memory space that is included in the hash calculation was not filled with a known value. Use your compiler's or Hexmate's fill option, or adjust the range of addresses used to calculate the hash.
  • Software breakpoints have been set when running code on the programmed device. The instructions at these locations are replaced with some form of break instruction by the MPLAB X IDE. If the opcodes of these break instructions are read to calculate a hash value at runtime, that hash value will be different from one calculated at compile time using the usual opcode values that reside at these locations in the HEX file.
The following is a common cause of failure for a number of Hexmate options.
  • Device addresses were used with Hexmate options, but the wrong addressing value was specified for the device. See the -addressing option (Addressing Hexmate Option) for the addressing value that should be used with your device if you intend to use device addresses with any options.