Before continuing with this section, please review the preceding sections to understand some of the implementation details that aren't discussed in detail in this section. Some of the implementation details of how this works is described the Understanding and Customizing the Boot Loader Implementation section. This section covers the basic flow and how it passes between the boot loader and the application.
In the boot loader implementations provided in USB Library library, the boot loader controls the interrupt vectors for PIC24F devices. The hardware interrupt vector table resides within the boot loader memory space. This means that the boot loader must jump to the appropriate user target application interrupt handler when an interrupt occurs. This processes in show below in the following diagram and described in the following paragraphs.
1) During the course of normal code execution, an interrupt occurs. The CPU vectors to the interrupt vector table (IVT) as described in the appropriate PIC24F datasheet.
2) The IVT is located in boot loader space, but the application needs to handle the interrupt. The boot loader jumps to the correct entry in the User Remapped Interrupt Vector Table. At this point the CPU is jumping from the boot loader memory space to the application memory space and effectively transferring control to the application.
3) At the entry in the User Remapped Interrupt Vector table there is placed a 'goto' instruction that will jump to the appropriate interrupt handler if one is defined in your application and to the default interrupt if there isn't a handler defined. In this way the behavior of the application with or without the boot loader is identical. The User Remapped Interrupt Vector table is created by the application linker file for the specific boot loader in use. This table is automatically generated and doesn't need to be modified. More about how this table is generated can be found in the Understanding and Customizing the Boot Loader Implementation.
4) Finally once the interrupt handler code is complete, the code will return from the interrupt handler. This will return the CPU to the instruction that the interrupt occurred before.
MLA - USB Library Help Version : 2.16
![]() |