Instant Interrupts - Revisited

[vamtbrider]

I think I have two problems.

One the jumper for bootloader mode is a PB that will tie portb.1 and 2 to ground when pressed. Walking through the bootloader code with the MPLAB debugger the portb inputs are not always on. Some times they are and sometimes they are not. I enabled the pull ups through the INCON2<7> but that doesn't seem to help. So I need to figure that out first.

A few times I have been able to get the DT_INTS-18 code with the blinky light to load into the PIC via the bootloader while still in debug mode in MPLABS. This has lead to the second problem.

When the interrupt comes in the code jumps to 0x008 which has a GOTO 0x808.
At 0x808 is another GOTO 0x998

running through the interrupt eventually gets to the code below:

1122   08C2    C017             MOVFF usb_sm_state, 0x90               
  1123   08C4    F090             NOP                                    
  1124   08C6    C018             MOVFF usb_sm_ctrl_state, 0x91          
  1125   08C8    F091             NOP                                    
  1126   08CA    C019             MOVFF usb_active_cfg, 0x92             
  1127   08CC    F092             NOP                                    
  1128   08CE    C01A             MOVFF usb_alt_intf, 0x93               
  1129   08D0    F093             NOP                                    
  1130   08D2    8022             BSF [0x22], 0                          
  1131   08D4    B414             BTFSC [0x14], 0x2                      
  1132   08D6    EF74             GOTO 0x8e8                             
  1133   08D8    F004             NOP                                    
  1134   08DA    C021             MOVFF 0x21, PCLATU                     
  1135   08DC    FFFB             NOP                                    
  1136   08DE    C020             MOVFF 0x20, PCLATH                     
  1137   08E0    FFFA             NOP                                    
  1138   08E2    501F             MOVF [0x1f], W                         
  1139   08E4    6AE0             CLRF BSR, ACCESS                       
  1140   08E6    6EF9             MOVWF PCL, ACCESS                      
  1141   08E8    C01E             MOVFF pSrc, PCLATU                     
  1142   08EA    FFFB             NOP                                    
  1143   08EC    C01D             MOVFF 0x1d, PCLATH                     
  1144   08EE    FFFA             NOP                                    
  1145   08F0    501C             MOVF [0x1c], W                         
  1146   08F2    6AE0             CLRF BSR, ACCESS                       
  1147   08F4    6EF9             MOVWF PCL, ACCESS                      
  1148   08F6    0004             CLRWDT                                 
  1149   08F8    A022             BTFSS [0x22], 0                        
  1150   08FA    EFB4             GOTO 0x968

the program resets after executing the instruction at 08F4 - MOVWF PCL, ACCESS. It looks like the WREG has a value of 0xDC that it is trying to stuff into PCL.

Basically the debugger stops stepping at that line, I click on the next line below it and select run to cursor the code restarts at 0x00. The bootloader checks the jumper, which is not there and then runs the app.

So basically it looks like the code keeps running to the first interrupt and then resetting the PIC.


I have attached a capture of the PIC Program Memory for what its worth.


I also loaded just the DT_INTS blinky light program onto the PIC without the bootloader. Using the MPLABS debugger i am able to see that when the code gets to the MOVWF PCL, ACCESS instruction it moves 0x34 from WREG into the PCL and the program jumps to 0x0234. The code at 0x0234 looks like the TOGGLELED1: code to actually toggle port b.0.
The code runs great without the bootloader.

Comparing the two pieces of code it looks like the bootloader version should be branching to 0x9DC...but instead I think its running off the stack and resetting the PIC.

I am now going to try and reload the DT_INTS with the bootloader and see if I can capture the PCL, PCLATH and PCLATU registers when the code attempts to move 0xDC into PCL. Hopefully I can see where it is really trying to go.

Its kind of late here in VA so I may have to tackle this tomorrow night.

Thanks for all the ideas so far.
Tom