Instant Interrupts - Revisited

[vamtbrider]

If I don't have the TRISB config the bootloader never enters the user program mode.

I added the TRISB = %1111110 and it enters the user program but still shows an undetected USB device after a few seconds and the LED on PORTB.0 is still not blinking.

One more piece of info, I am getting power from the USB port on my laptop. Even though the user program is not using USB I am "stealing" power for this test setup from the USB port. i.e. I download the program to the bootloader through the PIC USB and leave the cable connected to power the board for testing.

It doesn't look like anything in the DT_INTS would be triggered from activity on the USB port since I have not explicitly configured the USB_INT. The PIC is certainly seeing a request from the PC since its connected to the PIC circuitry and that could be why I get the USB device not recognized...although I don't get that when i am running just the Blink program using PAUSE 500 statements.

When I get home later tonight I will load this program directly on the PIC through the ICSP without the bootloader to verify my setup is happy. Then I will try the bootloader again and use an external power supply instead of the USB power.

ADDED: I have reconfigured the Bootloader to use PORT B.1 instead of Diolan's default of PortE.0. My end application will use Port B.1 so I built this test board assuming portb.1 would work.

[Darrel Taylor]

Try adding ...

DEFINE LOADER_USED 1

[Bruce]

Pheeeewwww! I do NOT like that loader at all.

I put one together for you here using the Microchip USB HID boot-loader. Give this one a shot. It works 100% with DT_INTS-18.

I modified the original C18 loader file so you can switch between the external crystal & internal osc at run-time to switch back-and-forth to various speeds.

Use a 20MHz crystal, 18F4550, and you should have no problems at all with the loader or DT_INTS-18.

Of course you'll need to download & install the Microchip HID USB loader PC app, but I find that one WAY nicer, and easier to use than the Diolan thing.

'****************************************************************
'*  Name    : USB_TST.BAS                                       *
'*  Author  : B. Reynolds                                       *
'*  Notice  : Copyright (c) 2010 http://www.Rentron.com         *
'*          : All Rights Reserved                               *
'*  Date    : 3/25/2010                                         *
'*  Version : 1.0                                               *
'*  Notes   : Using the Microchip USB HID Boot-Loader with PBP  *
'*          : and DT_INTS.                                      *
'****************************************************************
    
   ' Using the Microchip MCHPFSUSB v2.1 HID USB Bootloader with PBP & DT INTS.
    
   ' Place a 10K pull-up on RB4 with a switch to ground RB4 when pressed. 
    
   ' Loader mode. Press & hold switch on RB4, then press/release reset switch on /MCLR.
   ' Now release switch on RB4.
    
   ' LEDs on PORTD.0 & D.1 will blink on/off quickly showiing you're in loader mode
   ' and the MCHPFSUSB v2.1 HID PC bootloader software should now recognize your board.
    
   ' Open & load your compiled code, with the loader software, then press/release
   ' the switch on /MCLR, or click Reset Device on the loader software.
   
   ' Your code should now be running. 
    
   DEFINE OSC 48                   ' Loader configured for 20MHz OSC on USB board
   DEFINE RESET_ORG 0x1000         ' User code start location for HID loader  
    
   INCLUDE "DT_INTS-18.bas"        ' Base Interrupt System
   INCLUDE "ReEnterPBP-18.bas"     ' Include if using PBP interrupts                                           

   LED1   VAR PORTD.0
   Loops  VAR BYTE
    
   '   Hardware configuration
   '   ====================== 
   ADCON1  =   %00001111       ' All Digital                         


ASM
INT_LIST  macro     ; IntSource,    Label,     Type, ResetFlag?
        INT_Handler  TMR1_INT,  _ToggleLED1,   PBP,   yes
    endm
    INT_CREATE               ; Creates the interrupt processor
ENDASM    


T1CON = $31                ; Prescaler = 8, TMR1ON
@ INT_ENABLE  TMR1_INT     ; Enable Timer 1 interrupts

   OSCCON = %01110000     ; Switch to internal whenever you want by just
                          ; flipping OSCCON.1 to 1.
                          ; To run at 48MHz, flip OSCCON.1 back to 0..
Main:
   FOR Loops = 1 TO 6    ' we'll run at 48MHz here
     TOGGLE PORTD.1
     Pause 500
   NEXT Loops
  
   OSCCON.1 = 1          ' we'll run at 8MHz on internal osc here 
   FOR Loops = 1 TO 6
     TOGGLE PORTD.1
     Pause 500
   NEXT Loops
   
   OSCCON.1 = 0          ' flip switch back to 48MHz
   GOTO Main

'---[TMR1 - interrupt handler]--------------------------------------------------
ToggleLED1:
   TOGGLE LED1
@ INT_RETURN

    END

Some day when I have time I might figure the other one out, but this took a fraction of the time to change & test.

[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

[vamtbrider]

Ok, it looks like the code is trying to goto 0xa34 in the attached file.
It gets to 0x091C - MOVWF PCL, ACCESS and resets the PIC.

Here are the values for PC:

  Update      Address    Symbol Name      Value                      Binary     Char 

                 FE8     WREG                   0x34                  00110100    '4'
                 FF9     PCL                    0x1C                  00011100    '.'
                 FF9     PCLAT              0x0A341C 00001010 00110100 00011100  '.4.'
                 FFA     PCLATH                 0x34                  00110100    '4'
                 FFB     PCLATU                 0x0A                  00001010    '.'

The code should be going to 0x0A34 but instead resets...It never actually moves the 0x34 from Wreg into the PCL.

Any thoughts?

Thanks
Tom

[Bruce]

With the Diolan USB loader;

I would contact the author of your loader for help. His loader has extended instruction set enabled, and I don't think you're going to get PBP working on it with this enabled.

If you're having problems with the Microchip HID loader I posted, it's something specific to your setup. It works rock-solid on the Microchip PICDEM FS USB board I tested it on.

[vamtbrider]

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:

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?