Try adding ...
Code:DEFINE LOADER_USED 1
|
Try adding ...
Code:DEFINE LOADER_USED 1
DT
|
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.
Some day when I have time I might figure the other one out, but this took a fraction of the time to change & test.Code:'**************************************************************** '* 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
|
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:
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.Code: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
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
|
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:
The code should be going to 0x0A34 but instead resets...It never actually moves the 0x34 from Wreg into the PCL.Code: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 '.'
Any thoughts?
Thanks
Tom
|
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.
Last edited by Bruce; - 26th March 2010 at 08:54.
|
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:
If I look at the .LST file for the blinky led program I see this: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.
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.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
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?
|
I think there are two usb bootloaders from microchip. One is a HID Bootloader. I don't think it requires any dll's. It is located inside the huge files that you download as a group. Once all the Microchip Application Libraries v2010-02-09 is installed, the .hex file is located here: C:\Microchip Solutions\USB Device - Bootloaders\HID - BootloaderOriginally Posted by vamtbrider
I believe you can just bring the hidbootloader exe to a different computer, and program over the usb. But I have not fully tried it yet. I have only got to the point where my chip was regognized by a computer that has never had any microchip software loaded on it.
I need to try the executeable.
Members who have read this thread : 4You do not have permission to view the list of names.
Posting Permissions
Bookmarks