I will have to explore the Microchip bootloader a little more. I strayed away from it because I think it requires a .dll and I wanted a usb bootloader that would work with the standard microsoft drivers. The Diolan also uses encryption which is a very nice feature and the code size is slightly smaller.

Plus I like a challenge...maybe if I can get this working it will give others another option for bootloaders and DT_INTS.

So, on to what I have found today.

From section 26.2.4 of the 18f4550 manual:

Additionally, the Indexed Literal Offset Addressing
mode may create issues with legacy applications
written to the PIC18 assembler. This is because
instructions in the legacy code may attempt to address
registers in the Access Bank below 5Fh. Since these
addresses are interpreted as literal offsets to FSR2
when the instruction set extension is enabled, the
application may read or write to the wrong data
addresses.
If I look at the .LST file for the blinky led program I see this:
Code:
00037 FLAGS                           EQU     RAM_START + 000h
  00000001            00038 GOP                             EQU     RAM_START + 001h
  00000002            00039 R4                              EQU     RAM_START + 002h
  00000004            00040 R5                              EQU     RAM_START + 004h
  00000006            00041 R6                              EQU     RAM_START + 006h
  00000008            00042 R7                              EQU     RAM_START + 008h
  0000000A            00043 R8                              EQU     RAM_START + 00Ah
  0000000C            00044 INT_Flags                       EQU     RAM_START + 00Ch
  0000000D            00045 RM1                             EQU     RAM_START + 00Dh
  0000000E            00046 RM2                             EQU     RAM_START + 00Eh
  0000000F            00047 RR1                             EQU     RAM_START + 00Fh
  00000010            00048 RR2                             EQU     RAM_START + 010h
  00000011            00049 RS1                             EQU     RAM_START + 011h
  00000012            00050 RS2                             EQU     RAM_START + 012h
  00000013            00051 wsave                           EQU     RAM_START + 013h
  00000014            00052 RetAddrH                        EQU     RAM_START + 014h
  00000017            00053 RetAddrL                        EQU     RAM_START + 017h
Looking at the 2nd Capture.txt file I attached yesterday there are lots of MOVWF statements that reference the RAM areas above which are in RAM at locations under 0x5F.

So a statement like MOVWF [0x14] is really MOVWF [FSR2+0x14] with the extended instruction enabled. This may then explain why the code jumps off into la la land and resets.

I did not think to capture FSR2 last night during my debugging. I will do that tonight and see if it matches my theory. If it does then I think I will try to change the RAM_START to 0x060 so that the extended instruction engine will not use the FSR2 on the Ram addresses.

Am I on the right path?