Vault 7: Projects
This publication series is about specific projects related to the Vault 7 main publication.
1.6.3.2.1.9 QUERY_EXTENDED_INFO
The QUERY_EXTENDED_INFO command (0x0C) is used by the host PC application to get additional info about the device,
beyond the basic NVM layout provided by the QUERY_DEVICE command.
Description
The QUERY_EXTENDED_INFO command (0x0C) is used by the host PC application to get additional info about the device,
beyond the basic NVM layout provided by the QUERY_DEVICE command.
Table: QUERY_EXTENDED_INFO command format
Packet Byte Content
0 QUERY_EXTENDED_INFO
1-63 (padding)
The response packet to the QUERY_EXTENDED_INFO command is microcontroller architecture specific (ex: different
format for PIC18 versus PIC24 targets). See the the processor specific sections for the responses for each specific system.
1.6.3.2.2 Boot Loader Entry
This section discusses the methods of boot loader entry that are implemented in the example projects.
Description
When an application implements self reprogramming capability with a bootloader, some method needs to be implemented so
as to be able to enter into the bootloader “firmware update mode” (as opposed to the standard application run mode, where
self reprogramming is normally not performed).
There are lots of ways to end up in boot loader mode. The examples provided implement two possible methods for entry into
boot loader mode:
1. An I/O pin check at power-up/after any reset (ex: a user pressing a pushbutton attached to a general purpose input pin).
2. Software entry from the application run mode, into the bootloader firmware update mode, via an absolute jump to address
0x001C. This can be accomplished by receiving some application specific stimulus (ex: a custom command from a PC GUI
program intended to be used in conjunction with the USB application), and then in the firmware, executing an appropriate
goto instruction.
1.6.3.2.2.1 Input Button/Hardware Entry
Discusses hardware entry into boot loader mode.
Description
The HID bootloader firmware occupies the hardware reset vector of the microcontroller (ex: the reset vector is 0x0000, which
is part of the HID bootloader program memory space). During boot up of the microcontroller, firmware execution will
therefore begin from within the bootloader firmware project.
Early in the boot up sequence, the HID bootloader firmware can optionally perform a general purpose I/O pin check, which
would typically be connected to an external push button and pull up (or pull down) resistor. If the I/O pin is in the “active”
state (ex: user is actively pressing a button), as defined by the application, the HID bootloader firmware can decide to stay in
the “firmware update mode” and can therefore hold off normal execution of the application run mode image. If however the
I/O pin is in the inactive state (ex: button not pressed), then the boot up routine would normally decide to execute in
application run mode, and would perform a jump to the remapped application image reset vector (see Memory Map
Overview section).
The I/O pin check method is the most rugged method of entering the firmware update mode, since it does not require the
application firmware image to be intact (at all) to get into the bootloader mode. However, software entry is also possible and
may be more convenient in applications that do not have user exposed pushbutton(s) available.
1.6 Demos MLA - USB Library Help Device - Boot Loader - HID
248
Protego_Release_01_05-Related-OEM-Documentation-MLA_v2013_12_20-help_mla_usb.pdf