Post by thread:[PIC]: 18F452 problem with GO instruction?

I ported a large program written in PicBasic Pro from an 16F877 to an 18F452 to get more room. Only had to make a couple of changes. But I noticed a couple of funnies, where it appeared that an IF statement THEN clause was being entered when it shouldn't have. Much testing and I was able to produce a code fragment that duplicated the problem. I then wrote the fragment in assembler so I could post it here to the list to see if anyone has any thoughts as to what is going wrong. I'm using an older 452, a M'chip sample. But nothing in the errata documents suggests anything like this. Source code is below (in case anyone wants to try and duplicate the problem), followed by the MPASM listing, so you can see the generated code. If I do anything (change the ORG statement, or add NOPs ) to cause the label L1 to have an address not a multiple of 4, the LED stays dark. Or if I change the GOTO to a BRA followed by a NOP (to keep the address of L1 the same). Or if I add code AFTER the statement at L1. Otherwise, the LED flashes at an irregular (but fast) rate. This is my first foray into the world of the 18 series, so I may be missing something obvious. LIST P = 18F452, R = DEC, W = -302, F = INHX32 INCLUDE "P18F452.INC" ; MPASM Header test EQU 01AH ORG 0 ; Reset vector at 0 LIST __CONFIG _CONFIG1H, _OSCS_OFF_1H & _HS_OSC_1H __CONFIG _CONFIG2L, _BOR_ON_2L & _PWRT_ON_2L & _BORV_45_2L __CONFIG _CONFIG2H, _WDT_OFF_2H & _WDTPS_1_2H __CONFIG _CONFIG3H, _CCP2MX_ON_3H __CONFIG _CONFIG4L, _STVR_OFF_4L & _LVP_OFF_4L & _DEBUG_OFF_4L __CONFIG _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L __CONFIG _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H __CONFIG _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L __CONFIG _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H __CONFIG _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L __CONFIG _CONFIG7H, _EBTRB_OFF_7H ; ; Pseudo-code: (there is a LED connected to bit 1 of PORTC) ; The LED should never light, as bit0 is always zero. ; ; Set PORTC to output ; Clear PORTC ; Clear TEST ;Loop:if bit0 of TEST is 1 then ; toggle bit1 of portc 'toggle the LED ; endif ; goto loop clrf TRISC ; Set portc to output clrf portc ; Set portc pins low (LED is OFF) CLRF test ; Clear the variable ; ; Problem seems to occur when the target of the goto is an ; address that is NOT a multiple of 4. ; In the code below, L1 is at 14H. By changing the ORG statement ; or removing the NOP in the loop, or by adding another NOP - doing anything ; such that L1 ends up at an address that is a multiple of 4, the code works. ; That is, the LED does not flash. ; ; Also, by adding code (NOPs will do) AFTER the statement at L1, the code works ORG 000aH LOOP BTFSS test,0 ; IF bit0 is 1, skip to toggle LED GOTO L1 ; Bit0 is 0, don't toggle ; NOTE: we should never get here, since "test" was cleared initially ; but we do! ; The LED flashes at an irregular rate, as if sometime ; "test" is zero and sometimes not. ; Other tests have shown that "test" IS ALWAYS ZERO BTG PORTC,1 ; Toggle the LED ; If this NOP is removed (or if another one is added), the code works as it should nop L1 BRA LOOP ; If the NOP instruction below is commented out, the code above works as it should ; nop END MPASM LIsting: MPASM 03.20.07 Released T18BAD.ASM 11-10-2003 10:49:37 PAGE 1 LOC OBJECT CODE LINE SOURCE TEXT VALUE 00001 LIST P = 18F452, R = DEC, W = -302, F = INHX32 00002 INCLUDE "P18F452.INC" ; MPASM Header 00001 LIST 00002 ; P18F452.INC Standard Header File, Version 1.1 Microchip Technology, Inc. 00857 LIST 00003 00004 0000001A 00005 TEST EQU 01AH 00006 000000 00007 ORG 0 ; Reset vector at 0 00008 LIST 300000 FAFF 00009 __CONFIG _CONFIG1H, _OSCS_OFF_1H & _HS_OSC_1H 00010 __CONFIG _CONFIG2L, _BOR_ON_2L & _PWRT_ON_2L & _BORV_45_2L 300002 F0F2 00011 __CONFIG _CONFIG2H, _WDT_OFF_2H & _WDTPS_1_2H 300004 FFFF 00012 __CONFIG _CONFIG3H, _CCP2MX_ON_3H 300006 FFFA 00013 __CONFIG _CONFIG4L, _STVR_OFF_4L & _LVP_OFF_4L & _DEBUG_OFF_4L 00014 __CONFIG _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L 300008 FFFF 00015 __CONFIG _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H 00016 __CONFIG _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L 30000A FFFF 00017 __CONFIG _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H 00018 __CONFIG _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L 30000C FFFF 00019 __CONFIG _CONFIG7H, _EBTRB_OFF_7H 00020 00021 00022 ; 00023 ; Psuedo-code: (there is a LED connected to bit 1 of PORTC) 00024 ; 00025 ; Set PORTC to output 00026 ; Clear PORTC 00027 ; Clear TEST 00028 ;Loop:if bit0 of TEST is 1 then 00029 ; toggle bit1 of portc 'toggle the LED 00030 ; endif 00031 ; goto loop 00032 00033 000000 6A94 00034 CLRF TRISC ; Set portc to output 000002 6A82 00035 CLRF PORTC ; Set portc pins low (LED is OFF) 00036 000004 6A1A 00037 CLRF TEST ; Clear the variable 00038 ; 00039 ; Problem seems to occur when the target of the goto is an 00040 ; address that is NOT a multiple of 4. 00041 ; In the code below, L1 is at 14H. By changing the ORG statement 00042 ; or removing the NOP in the loop, or by adding another NOP - doing anything 00043 ; such that L1 ends up at an address that is a multiple of 4, the code works. 00044 ; That is, the LED does not flash. 00045 ; 00046 ; Also, by adding code (NOPs will do) AFTER the statement at L1, the code works 00047 00048 00000A 00049 ORG 000AH 00000A A01A 00050 LOOP BTFSS TEST,0 ; IF bit0 is 1, skip to toggle LED 00000C EF0A F000 00051 GOTO L1 ; Bit0 is 0, don't toggle 00052 00053 ; NOTE: we should never get here, since "test" was cleared initially 00054 ; but we do! 00055 ; The LED flashes at an irregular rate, as if sometime 00056 ; "test" is zero and sometimes not. 00057 ; Other tests have shown that "test" IS ALWAYS ZERO 00058 000010 7282 00059 BTG PORTC,1 ; Toggle the LED 00060 ; If this NOP is removed (or if another one is added), the code works as it should 000012 0000 00061 NOP 000014 D7FA 00062 L1 BRA LOOP 00063 00064 ; If the NOP instruction below is commented out, the code above works as it should 00065 ; nop 00066 00067 END Larry Bradley Orleans (Ottawa), Ontario, CANADA -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

Resent using a fixed font (I hope): I ported a large program written in PicBasic Pro from an 16F877 to an 18F452 to get more room. Only had to make a couple of changes. But I noticed a couple of funnies, where it appeared that an IF statement THEN clause was being entered when it shouldn't have. Much testing and I was able to produce a code fragment that duplicated the problem. I then wrote the fragment in assembler so I could post it here to the list to see if anyone has any thoughts as to what is going wrong. I'm using an older 452, a M'chip sample. But nothing in the errata documents suggests anything like this. Source code is below (in case anyone wants to try and duplicate the problem), followed by the MPASM listing, so you can see the generated code. If I do anything (change the ORG statement, or add NOPs ) to cause the label L1 to have an address not a multiple of 4, the LED stays dark. Or if I change the GOTO to a BRA followed by a NOP (to keep the address of L1 the same). Or if I add code AFTER the statement at L1. Otherwise, the LED flashes at an irregular (but fast) rate. This is my first foray into the world of the 18 series, so I may be missing something obvious. LIST P = 18F452, R = DEC, W = -302, F = INHX32 INCLUDE "P18F452.INC" ; MPASM Header test EQU 01AH ORG 0 ; Reset vector at 0 LIST __CONFIG _CONFIG1H, _OSCS_OFF_1H & _HS_OSC_1H __CONFIG _CONFIG2L, _BOR_ON_2L & _PWRT_ON_2L & _BORV_45_2L __CONFIG _CONFIG2H, _WDT_OFF_2H & _WDTPS_1_2H __CONFIG _CONFIG3H, _CCP2MX_ON_3H __CONFIG _CONFIG4L, _STVR_OFF_4L & _LVP_OFF_4L & _DEBUG_OFF_4L __CONFIG _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L __CONFIG _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H __CONFIG _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L __CONFIG _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H __CONFIG _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L __CONFIG _CONFIG7H, _EBTRB_OFF_7H ; ; Pseudo-code: (there is a LED connected to bit 1 of PORTC) ; The LED should never light, as bit0 is always zero. ; ; Set PORTC to output ; Clear PORTC ; Clear TEST ;Loop:if bit0 of TEST is 1 then ; toggle bit1 of portc 'toggle the LED ; endif ; goto loop clrf TRISC ; Set portc to output clrf portc ; Set portc pins low (LED is OFF) CLRF test ; Clear the variable ; ; Problem seems to occur when the target of the goto is an ; address that is NOT a multiple of 4. ; In the code below, L1 is at 14H. By changing the ORG statement ; or removing the NOP in the loop, or by adding another NOP - doing anything ; such that L1 ends up at an address that is a multiple of 4, the code works. ; That is, the LED does not flash. ; ; Also, by adding code (NOPs will do) AFTER the statement at L1, the code works ORG 000aH LOOP BTFSS test,0 ; IF bit0 is 1, skip to toggle LED GOTO L1 ; Bit0 is 0, don't toggle ; NOTE: we should never get here, since "test" was cleared initially ; but we do! ; The LED flashes at an irregular rate, as if sometime ; "test" is zero and sometimes not. ; Other tests have shown that "test" IS ALWAYS ZERO BTG PORTC,1 ; Toggle the LED ; If this NOP is removed (or if another one is added), the code works as it should nop L1 BRA LOOP ; If the NOP instruction below is commented out, the code above works as it should ; nop END MPASM LIsting: MPASM 03.20.07 Released T18BAD.ASM 11-10-2003 10:49:37 PAGE 1 LOC OBJECT CODE LINE SOURCE TEXT VALUE 00001 LIST P = 18F452, R = DEC, W = -302, F = INHX32 00002 INCLUDE "P18F452.INC" ; MPASM Header 00001 LIST 00002 ; P18F452.INC Standard Header File, Version 1.1 Microchip Technology, Inc. 00857 LIST 00003 00004 0000001A 00005 TEST EQU 01AH 00006 000000 00007 ORG 0 ; Reset vector at 0 00008 LIST 300000 FAFF 00009 __CONFIG _CONFIG1H, _OSCS_OFF_1H & _HS_OSC_1H 00010 __CONFIG _CONFIG2L, _BOR_ON_2L & _PWRT_ON_2L & _BORV_45_2L 300002 F0F2 00011 __CONFIG _CONFIG2H, _WDT_OFF_2H & _WDTPS_1_2H 300004 FFFF 00012 __CONFIG _CONFIG3H, _CCP2MX_ON_3H 300006 FFFA 00013 __CONFIG _CONFIG4L, _STVR_OFF_4L & _LVP_OFF_4L & _DEBUG_OFF_4L 00014 __CONFIG _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L 300008 FFFF 00015 __CONFIG _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H 00016 __CONFIG _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & _WRT2_OFF_6L & _WRT3_OFF_6L 30000A FFFF 00017 __CONFIG _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H 00018 __CONFIG _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L 30000C FFFF 00019 __CONFIG _CONFIG7H, _EBTRB_OFF_7H 00020 00021 00022 ; 00023 ; Psuedo-code: (there is a LED connected to bit 1 of PORTC) 00024 ; 00025 ; Set PORTC to output 00026 ; Clear PORTC 00027 ; Clear TEST 00028 ;Loop:if bit0 of TEST is 1 then 00029 ; toggle bit1 of portc 'toggle the LED 00030 ; endif 00031 ; goto loop 00032 00033 000000 6A94 00034 CLRF TRISC ; Set portc to output 000002 6A82 00035 CLRF PORTC ; Set portc pins low (LED is OFF) 00036 000004 6A1A 00037 CLRF TEST ; Clear the variable 00038 ; 00039 ; Problem seems to occur when the target of the goto is an 00040 ; address that is NOT a multiple of 4. 00041 ; In the code below, L1 is at 14H. By changing the ORG statement 00042 ; or removing the NOP in the loop, or by adding another NOP - doing anything 00043 ; such that L1 ends up at an address that is a multiple of 4, the code works. 00044 ; That is, the LED does not flash. 00045 ; 00046 ; Also, by adding code (NOPs will do) AFTER the statement at L1, the code works 00047 00048 00000A 00049 ORG 000AH 00000A A01A 00050 LOOP BTFSS TEST,0 ; IF bit0 is 1, skip to toggle LED 00000C EF0A F000 00051 GOTO L1 ; Bit0 is 0, don't toggle 00052 00053 ; NOTE: we should never get here, since "test" was cleared initially 00054 ; but we do! 00055 ; The LED flashes at an irregular rate, as if sometime 00056 ; "test" is zero and sometimes not. 00057 ; Other tests have shown that "test" IS ALWAYS ZERO 00058 000010 7282 00059 BTG PORTC,1 ; Toggle the LED 00060 ; If this NOP is removed (or if another one is added), the code works as it should 000012 0000 00061 NOP 000014 D7FA 00062 L1 BRA LOOP 00063 00064 ; If the NOP instruction below is commented out, the code above works as it should 00065 ; nop 00066 00067 END Larry Bradley Orleans (Ottawa), Ontario, CANADA -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

See comments on your code below:- > > test EQU 01AH > > ORG 0 ; Reset vector at 0 > LIST That "LIST" shouldn't be in there. {Quote hidden}> __CONFIG _CONFIG1H, _OSCS_OFF_1H & _HS_OSC_1H > __CONFIG _CONFIG2L, _BOR_ON_2L & _PWRT_ON_2L & _BORV_45_2L > __CONFIG _CONFIG2H, _WDT_OFF_2H & _WDTPS_1_2H > __CONFIG _CONFIG3H, _CCP2MX_ON_3H > __CONFIG _CONFIG4L, _STVR_OFF_4L & _LVP_OFF_4L & _DEBUG_OFF_4L > __CONFIG _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L > & _CP3_OFF_5L > __CONFIG _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H > __CONFIG _CONFIG6L, _WRT0_OFF_6L & _WRT1_OFF_6L & > _WRT2_OFF_6L & _WRT3_OFF_6L > __CONFIG _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H > __CONFIG _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & > _EBTR2_OFF_7L & _EBTR3_OFF_7L > __CONFIG _CONFIG7H, _EBTRB_OFF_7H > > I'd recommend you put the config stuff in another ASM file in your project. makes things neater. {Quote hidden}> ; > ; Pseudo-code: (there is a LED connected to bit 1 of PORTC) > ; The LED should never light, as bit0 is always zero. > ; > ; Set PORTC to output > ; Clear PORTC > ; Clear TEST > ;Loop:if bit0 of TEST is 1 then > ; toggle bit1 of portc 'toggle the LED > ; endif > ; goto loop > > > clrf TRISC ; Set portc to output > clrf portc ; Set portc pins low (LED is OFF) > > CLRF test ; Clear the variable Above you specified "org 0x00". So, these first three instructions go to program memory addresses 0x0000, 0x0002 and 0x0004. {Quote hidden}> ; > ; Problem seems to occur when the target of the goto is an > ; address that is NOT a multiple of 4. > ; In the code below, L1 is at 14H. By changing the ORG > statement ; or removing the NOP in the loop, or by adding > another NOP - doing anything ; such that L1 ends up at an > address that is a multiple of 4, the code works. ; That is, > the LED does not flash. ; ; Also, by adding code (NOPs will > do) AFTER the statement at L1, the code works > > > ORG 000aH oops, you just gave another ORG. so, the program memory from 0x0006 up to 0x0009 is uninitialised. But you didn't branch over it. Who knows what it contains? {Quote hidden}> LOOP BTFSS test,0 ; IF bit0 is 1, skip to toggle LED > GOTO L1 ; Bit0 is 0, don't toggle > > ; NOTE: we should never get here, since "test" was cleared > initially ; but we do! ; The LED flashes at an irregular > rate, as if sometime ; "test" is zero and sometimes not. ; > Other tests have shown that "test" IS ALWAYS ZERO > > BTG PORTC,1 ; Toggle the LED > ; If this NOP is removed (or if another one is added), the > code works as it should > nop > L1 BRA LOOP > I prefer to put labels on separate lines:- L1: BRA LOOP Anyway, the fact that you're trying to execute un-programmed program memory might be the cause of the problem here. I guess it depends on what your programmer does with this memory. Just lose the second ORG (the ORG 000aH). Jon -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

> > Why? IIRC that is the second interrupt vector for an 18F > series. No, they are at 0x0008 (high priority) and 0x00018 (low priority). So, there's no reason to be not using that code space. > I suspect this is possibly a second reason for the > led blinking intermittently, and interrupts are > un-initialised, although they are not explicitly enabled, and > so should not really worry the code. Interupts are configured in a known state on POR, ie all disabled. > The only possibility of > trouble here is that the uncoded area may have something in > it, but IIRC a memory word of 0xFFFF is a NOP for an 18F, but > I could be wrong. It is. 0x0000 and 0xFFFF are NOP, as is any unregognised program word. However, if we assume that his programmer did not clear the program memory (and why would it- if the programming phase had to erase first, it'd erase the entire range of memeory which is 32k, and would take ages), then remnants of whatever the OP originally posted probably remain here. And considering he's been fiddling around trying to get this working, then it seems fairly likely there are some branches, and set / clear / toggle portc type instructions. Jon -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.