USB Library
Software/Application Entry

Optionally, the HID bootloader firmware may be configured to allow entry into the bootloader firmware update mode via software entry at application runtime. This would typically be performed by:

  1. Allowing the microcontroller to boot up into normal application run mode (as opposed to firmware update mode).
  2. While in application run mode, some application specific event occurs, whereby the application decides it wants to switch into firmware update mode.
  3. The firmware executes an absolute “goto” instruction to jump to the software entry point into the HID bootloader (0x001C for PIC16 and PIC18 based projects).
  4. The bootloader begins executing and keeps the processor in application firmware update mode, until the user has finished programming a new application run mode firmware image.
The software entry method stimulus event (step #2 above) is application specific, and needs to be implemented in the application firmware image project (ex: the code associated with it does not reside in the bootloader firmware program space). Typically, this would be implemented by having some custom host/PC application GUI program that sends a custom command to the application firmware image (in normal “application run mode” over the normal application USB endpoints), letting it know it should switch into the HID bootloader firmware update mode. 

The software entry method is generally not as “rugged” as the I/O pin check entry method however. The software entry method necessarily requires that the application firmware image be intact and functional, prior to receiving the stimulus needed to switch into the firmware update mode. Therefore, programming a non-functional application firmware image into the microcontroller, could prevent further entry back into the firmware update mode (needed for re-programming another application firmware image). This creates a so called “chicken and egg” scenario, where recovery is not possible (without reprogramming the microcontroller with a conventional ICSP™ based programming tool, such as the PICkit 3 or MPLAB ICD 3 programmer/debugger devices). 

However, some recoverability in the event of failed reprogramming sequences, such as the case of sudden power loss or the user unplugging the USB cable during the erase/program/verify sequence, is possible. This is achieved through the “Flash Signature Process”. 

The software based entry method into the bootloader firmware update mode is optional, and is not mutually exclusive with the I/O pin check method. Applications may choose to use either or both entry methods as desired. The software entry method is always available (even if not used). The I/O pin entry method can be enabled or disabled based on the usb_config.h settings in the HID bootloader firmware project. 

If the software entry method will be used, the entry into the firmware update mode can be accomplished by executing the appropriate software entry routine. 

Software Entry for PIC16 Devices  

#asm
    movlp 0x00    //most significant bits of dest, needed for PIC16 devices
    goto 0x001C
#endasm

Software Entry for PIC18 Devices

#asm
    goto 0x001C
#endasm

The above assumes the XC8 compiler is used. If the MPLAB C18 compiler is used instead, the #asm and #endasm should be changed to _asm and _endasm respectively.

NOTE: When the "application" image is executing, the application may jump into firmware update mode by executing the appropriate goto instruction. Before doing so however, the firmware should configure the current clock settings to be compatible with USB module operation, if they are not already. Once the goto 0x001C has been executed, the USB device will detach from the USB bus (if it was previously attached), and will re-enumerate as a HID class device with a new VID/PID (adjustable via usb_descriptors.c settings in bootloader firmware), which can communicate with the associated USB host software that loads and programs the new application .hex file. 
MLA - USB Library Help Version : 2.16
http://www.microchip.com/mla