 |
 |
| View previous topic :: View next topic |
| Author |
Message |
zilog
Joined: 17 Aug 2007
Posts: 19
|
| EXT_INT3 interrupt always placed as high priority? |
 Posted: Wed Aug 22, 2007 6:03 am |
 |
|
I am using CCS 3.249 with a PIC 18F66J15 MCU. I am using INT_RB as the only high priority interrupt, and I have enabled high ints with
| Code: |
#device HIGH_INTS=TRUE
|
I dont use any priorities as I only have one int marked as high. The strange thing is that when I look at main.lst, I see that INT_EXT3 AND INT_RB are both placed as high priority - why this? In the datasheet for the PIC, I can choose between low and high priority for this pin.
Is there any work around for this? I still need INT_RB as high since it serves very time critical stuff. |
|
 |
Ttelmah
Guest
|
|
| Posted: Wed Aug 22, 2007 9:41 am |
|
|
Hm.
| Code: |
#include <18F66J15.h>
#device adc=8
#device HIGH_INTS=TRUE
#FUSES NOWDT,WDT128,E4_SW_IO,NODEBUG,NOXINST,STVREN,NOPROTECT,FCMEN,NOIESO,PRIMARY
#use delay(clock=20000000)
#use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=9)
#int_timer3
void timer_int(void) {
}
#int_rb HIGH
void b_changed(void) {
int8 dummy;
dummy=input_b();
}
void main() {
setup_adc_ports(NO_ANALOGS|VSS_VDD);
setup_adc(ADC_OFF|ADC_TAD_MUL_0);
setup_psp(PSP_DISABLED);
setup_spi(FALSE);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
setup_timer_4(T4_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_oscillator(False);
enable_interrupts(INT_RB);
enable_interrupts(INT_TIMER3);
enable_interrupts(GLOBAL);
while (true) {
}
}
|
Correctly generates the two interrupt handlers, and sets the priority bit for RB.
| Code: |
00000: GOTO 0150
*
00008: GOTO 00B4 //vector to high priority handler
0000C: NOP
0000E: NOP
00010: NOP
00012: NOP
00014: NOP
00016: NOP
00018: MOVWF 05 //start of low priority handler
0001A: MOVFF FD8,06
0001E: MOVFF FE0,07
00022: MOVLB 0
00024: MOVFF FE9,0D
00028: MOVFF FEA,08
0002C: MOVFF FE1,09
00030: MOVFF FE2,0A
00034: MOVFF FD9,0B
00038: MOVFF FDA,0C
0003C: MOVFF FF3,14
00040: MOVFF FF4,15
00044: MOVFF FFA,16
00048: MOVFF FFB,17
0004C: MOVFF 00,0F
00050: MOVFF 01,10
00054: MOVFF 02,11
00058: MOVFF 03,12
0005C: MOVFF 04,13
00060: BTFSS FA0.1
00062: GOTO 006C
00066: BTFSC FA1.1
00068: GOTO 013C
0006C: MOVFF 0F,00
00070: MOVFF 10,01
00074: MOVFF 11,02
00078: MOVFF 12,03
0007C: MOVFF 13,04
00080: MOVFF 0D,FE9
00084: MOVFF 08,FEA
00088: MOVFF 09,FE1
0008C: MOVFF 0A,FE2
00090: MOVFF 0B,FD9
00094: MOVFF 0C,FDA
00098: MOVFF 14,FF3
0009C: MOVFF 15,FF4
000A0: MOVFF 16,FFA
000A4: MOVFF 17,FFB
000A8: MOVF 05,W
000AA: MOVFF 07,FE0
000AE: MOVFF 06,FD8
000B2: RETFIE 0
000B4: MOVLB 0 //start of high priority register save
|
There is a 'caveat', with the 'J' chips, and 3.249, the fuses will not be correctly set by this compiler. You need to manually handle this (either add a ROM statement to set them, or do it in your programmer), or the code won't work.
Best Wishes |
|
|
zilog
Joined: 17 Aug 2007
Posts: 19
|
|
| Posted: Wed Aug 22, 2007 9:48 am |
|
|
| Ttelmah, I dont really understand what you mean with fuses being set the wrong way? Does this affect the problem I am experiencing with the compiler making INT_EXT3 high priority? |
|
|
zilog
Joined: 17 Aug 2007
Posts: 19
|
|
| Posted: Wed Aug 22, 2007 9:55 am |
|
|
Btw. I also have a question regarding context saving upon entry to interrupts, what I can see in
| Code: |
00000: GOTO 58D8
*
00008: GOTO 00FC
0000C: NOP
0000E: NOP
00010: NOP
00012: NOP
00014: NOP
00016: NOP
00018: MOVWF 05
0001A: MOVFF FD8,06
0001E: MOVFF FE0,07
00022: MOVLB 0
00024: MOVFF FE9,0D
00028: MOVFF FEA,08
0002C: MOVFF FE1,09
00030: MOVFF FE2,0A
00034: MOVFF FD9,0B
00038: MOVFF FDA,0C
0003C: MOVFF FF3,14
00040: MOVFF FF4,15
00044: MOVFF FFA,16
00048: MOVFF FFB,17
0004C: MOVFF 00,0F
00050: MOVFF 01,10
00054: MOVFF 02,11
00058: MOVFF 03,12
0005C: MOVFF 04,13
00060: BTFSS FF2.5
00062: GOTO 006C
00066: BTFSC FF2.2
00068: GOTO 0EE0
0006C: BTFSS F9D.0
0006E: GOTO 0078
00072: BTFSC F9E.0
00074: GOTO 1BEE
00078: BTFSS F9D.1
0007A: GOTO 0084
0007E: BTFSC F9E.1
00080: GOTO 1E62
00084: BTFSS F9D.5
00086: GOTO 0090
0008A: BTFSC F9E.5
0008C: GOTO 154E
00090: BTFSS F9D.4
00092: GOTO 009C
00096: BTFSC F9E.4
00098: GOTO 0F4E
0009C: BTFSS FA3.5
0009E: GOTO 00A8
000A2: BTFSC FA4.5
000A4: GOTO 1F26
000A8: BTFSS FA3.4
000AA: GOTO 00B4
000AE: BTFSC FA4.4
000B0: GOTO 215A
000B4: MOVFF 0F,00
000B8: MOVFF 10,01
000BC: MOVFF 11,02
000C0: MOVFF 12,03
000C4: MOVFF 13,04
000C8: MOVFF 0D,FE9
000CC: MOVFF 08,FEA
000D0: MOVFF 09,FE1
000D4: MOVFF 0A,FE2
000D8: MOVFF 0B,FD9
000DC: MOVFF 0C,FDA
000E0: MOVFF 14,FF3
000E4: MOVFF 15,FF4
000E8: MOVFF 16,FFA
000EC: MOVFF 17,FFB
000F0: MOVF 05,W
000F2: MOVFF 07,FE0
000F6: MOVFF 06,FD8
000FA: RETFIE 0
|
The compiler just moves "W" to x05, without looking at BSR beforehand (and writing over whatever was at x05?). I have tried to look at the .hex file to see whether or not the "a" bit is set in this instruction, but I dont get any wiser from this as I cant recognize anything in main.hex... are the adresses in main.lst really the ones that end up in main.hex? Have a look at the attached block - shouldn't there be a "goto 58D8" at address zero?
| Code: |
:020000040000FA
:040000006CEF2CF085
:080008007EEF00F00000000093
:100010000000000000000000056ED8CF06F0E0CF21
:1000200007F00001E9CF0DF0EACF08F0E1CF09F0C9
:10003000E2CF0AF0D9CF0BF0DACF0CF0F3CF14F007
:10004000F4CF15F0FACF16F0FBCF17F000C00FF089
:1000500001C010F002C011F003C012F004C013F090
:10006000F2AA36EF00F0F2B470EF07F09DA03CEF7B
:1000700000F09EB0F7EF0DF09DA242EF00F09EB2AF
:1000800031EF0FF09DAA48EF00F09EBAA7EF0AF0FB
:100090009DA84EEF00F09EB8A7EF07F0A3AA54EF7B
:1000A00000F0A4BA93EF0FF0A3A85AEF00F0A4B8A1
:1000B000ADEF10F00FC000F010C001F011C002F061
:1000C00012C003F013C004F00DC0E9FF08C0EAFF3E
:1000D00009C0E1FF0AC0E2FF0BC0D9FF0CC0DAFF84
:1000E00014C0F3FF15C0F4FF16C0FAFF17C0FBFFE2
:1000F000055007C0E0FF06C0D8FF10000001E9CF9F
|
EDIT: I just found out that the ACCESS bank is being used in the MOVWF, nevermind this question. Still wondering about the fuses though. |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Aug 22, 2007 10:25 am |
|
|
The lack of bank handling in the low priority hanlder, is a bug.
The failure to load the fuses, normally prevents the processor running at all...
The actual start of main, is 154. Why the list shows 58D8, I don't know.
Best Wishes |
|
|
zilog
Joined: 17 Aug 2007
Posts: 19
|
|
| Posted: Wed Aug 22, 2007 11:35 am |
|
|
| Ttelmah wrote: | The lack of bank handling in the low priority hanlder, is a bug.
|
Is this an official compiler bug?
| Ttelmah wrote: |
The actual start of main, is 154. Why the list shows 58D8, I don't know.
Best Wishes |
You must be confusing my code with your listing, my main starts way later in the code. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Wed Aug 22, 2007 3:32 pm |
|
|
| zilog wrote: | | Ttelmah wrote: | The lack of bank handling in the low priority hanlder, is a bug.
|
Is this an official compiler bug? |
I'm sorry to disappoint you both, but this is not a bug.
| Code: | 00018: MOVWF 05 // save W
0001A: MOVFF FD8,06 // save Status
0001E: MOVFF FE0,07 // save BSR
00022: MOVLB 0 |
This compiler generated code is the same as shown in the PIC18F87J10 Family datasheet chapter 9.9, 'context saving during interrupts'.
There are two key issues here:
- You can't set the BSR register before it is saved (chicken/egg problem). Setting the BSR also modifies the Status register, that's why BSR is only set in line four.
- The MOVWF instruction has a second parameter not shown here. This additional parameter tells the processor to use either bank 0, or the BSR indicated bank. You can check this parameter to be set correctly from MPLAB's Assembly View window.
Precondition for the MOVWF to work like this is that the W-save storage is located in bank 0. Address 0x0005 complies to this.
The code would have been easier to understand had CCS used MOVFF instead of MOVWF, but CCS is paid to generate optimized code, not for easy to read code. MOVFF takes two bytes more memory and one more instruction cycle than a MOVWF. The same code is present at the end of the interrupt handler, doubling the savings in our time critical interrupt handlers.
Note 1: The code for the High priority interrupt is slightly different as this uses the hardware based fast return stack which automatically saves W, Status and BSR. Only one such stack exists so it can not be used for both high and low priorities.
Note 2: CCS didn't get it right the first time either, version v3.238 added a missing bank switch for the high priority interrupts. |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Aug 23, 2007 4:26 am |
|
|
Yes.
What is 'wrong', is that their listing, does not show that they are using the access bank mode. I consider this a bug in the assembler itself, but at least one that won't kill the program!.
On the 'goto', you won't see '58d8' in the assembler, since the instruction itself, is combined with the required address.
The fuses are the killer though. Basically, the 'J' chips function differently from all older PICs. On the older PICs the configuration fuses are loaded at 300000 in the memory, which is ROM, and programmed with the rest of the chip. On the J chips, the area at this point is RAM, but is only writable by resetting the processor, which then automatically copies the bytes held in the top few words of the normal memory, into this area. The 3.249 compiler, still puts the cnfiguration bytes at the 'normal' address, so the top of memory, gets programmed with 'sleep' instructions, and it is _these_ that get written to the config memory. This normally stops the processor running at all (since the oscillator etc., are set incorrectly).
The solution, is to use the #ROM directive in your code, to put the correct configuration bytes into the top of the program ROM. The byte sequence required, is at the end of the hex file generated (where it is written to 300000), and you can just use this byte sequence and add it to the code in the right location (0x17FF8 for your processor).
I think this is why your code is not working, and nothing to do with the interrupt handler at all.
Best Wishes |
|
|
Mogge
Joined: 13 Aug 2007
Posts: 14
Location: Sweden
|
|
| Posted: Mon Aug 27, 2007 3:15 pm |
|
|
Thanks Ttelmah
We still have not found the cause to the problem.
We are intending rewrite to C18, which is not easy.
Even if the problem is not caused by CCS compiler, the rewrite might make us find a problem, and also the REAL-ICE debugger is supported so we can track what is happening better.
But we will not make it to the deadline... |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
