Vault 7: Projects
This publication series is about specific projects related to the Vault 7 main publication.
operations, since the .hex file may contain a ‘1’ or ‘0’ in these locations, even though the microcontroller hardware may not
implement some of these locations. If the PC GUI application were to attempt to verify these locations, they would therefore
always read back as the default unimplemented value (ex: 0 for PIC18 devices), which may not necessarily match the .hex
file (ex: if it had a ‘1’ in the same location). Therefore, the firmware should properly respond to the host’s
QUERY_EXTENDED_INFO command, with AND mask values that the PC GUI program should use to AND the .hex file
values before comparing them to the read values, ensuring that the verify operation successfully ignores
unimplemented/unimportant locations.
1.6.3.2.3.1.3 Changing the Memory Footprint
Describes how to change the location and size of the memory that the boot loader uses.
Description
By default, the bootloader firmware project reserves and occupies the 0x000-0xFFF region (PIC18) or 0x000-0x8FF (PIC16)
program memory region. It is possible to move this boundary (ex: if more space is needed for the bootloader firmware, such
as when trying to build/use the bootloader with a free/non-optimizing version of the C compiler).
In order to move the boundary, the new boundary must be chosen that aligns perfectly with a native flash memory erase
block size (ex: the boundary cannot reside in the middle of an flash memory erase page). Additionally, moving the boundary
requires changing the bootloader definitions (REMAPPED_APPLICATION_RESET_VECTOR,
REMAPPED_APPLICATION_HIGH_ISR_VECTOR, REMAPPED_APPLICATION_LOW_ISR_VECTOR,
APP_SIGNATURE_ADDRESS, APP_VERSION_ADDRESS) in both the bootloader firmware project, as well as in the
application firmware project intended to be programmed by the bootloader firmware.
When moving the APP_SIGNATURE_ADDRESS, make sure that the newly selected address always resides fully on the
very first flash memory erase page that gets erased by the bootloader, in order to avoid defeating the robustness features
offered by the flash signing process.
Additionally, both the bootloader firmware project and application linker settings must be modified. When using the C18
compiler, this entails modifying both the application and bootloader firmware .lkr files, so as to allocate more space for the
bootloader. When using the XC8 compiler, the linker settings must be modified in both the bootloader firmware build
configuration, as well as the application firmware image project build configuration.
1.6.3.2.3.1.4 C18 Compiler
Discusses how to use the C18 compiler with the boot loader examples.
Description
The C18 compiler only supports PIC18 based targets, and therefore, this section is only relevant for PIC18 devices. For
PIC16 or PIC18 targets using the XC8 compiler, see the XC8 Compiler section.
The PIC18F HID bootloader firmware is compatible with both the C18 and XC8 compilers. When the firmware is build with
the C18 compiler, the bootloader project needs to be built with the all of the compiler optimizations full enabled, and using
the Default Storage Class “Static”. Using a free/unlicensed version of the compiler will not directly work, as some of the
compiler optimizations are disabled in the free version.
If the firmware project is built without the full compiler optimizations enabled, the total code size will be too large to fit within
the program memory range 0x000-0xFFF reserved by default for the bootloader firmware. It is possible, albeit not preferred,
to move the bootloader/application program memory space boundary, so as to allocate/reserve more flash memory for the
bootloader, if the bootloader will be built without full compiler optimizations enabled. See “Moving the Application/Bootloader
Flash Boundary”.
The bootloader project is provided with the modified linker scripts to be used with the bootloader project (ex:
BootModified.18f14k50_g.lkr), and modified example linker scripts that can be used with the application projects (ex: Linker
files for applications\ rm18f14k50_g.lkr). However, certain application projects may require a slightly modified application
linker script (ex: projects using large RAM buffers > 256 bytes in size for instance), but the provided application linker files
should still be used as a template/starting point when configuring the linker script.
1.6 Demos MLA - USB Library Help Device - Boot Loader - HID
253
Protego_Release_01_05-Related-OEM-Documentation-MLA_v2013_12_20-help_mla_usb.pdf