LED turns off when jumping to a routine

I have a funny issue I have been dealing with for some time and can't figure it out.

I am using a 16F1829 and have the LED on porta.5

During my startup routine, I have porta.5 setup for digital, no pull ups, the latch register is set to low and the tris register is set for input.

When I turn on a feature on my project, I turn the LED on by flipping the tris register to an output. This lets the customer know that the feature is on.

Now when they press another button, the code does a jump (gosub) to a routine. When this happens, it turns the LED off.

For the life of me, I can't understand why.

Here is my startup configuration

Code:

---


DEFINE OSC 32
PORTA = 0
PORTB = 0
PORTC = 0
'***************************************************************
'*****************CONFIGURATION WORDS IN INCLUDE****************
'***************************************************************

'__CONFIG _CONFIG1, _FCMEN_ON, _IESO_OFF, _CLKOUTEN_OFF, _BOREN_OFF, _CPD_OFF, _CP_OFF, _MCLRE_ON, _PWRTE_OFF, _WDTE_OFF, _FOSC_INTOSC
'__CONFIG _CONFIG2, _LVP_ON, _BORV_19, _STVREN_OFF, _PLLEN_ON, _WRT_OFF

'***************************************************************
'********************SET STANDARD REGISTERS*********************
'***************************************************************

''''''OSCILLATOR REGISTERS'''''
OSCCON = %11110000
OSCTUNE = %011111

''''''PORT REGISTERS'''''''''''
OPTION_REG = %00000000
ADCON0 = %00000000
ADCON1 = %00000000
DACCON0 = %00000000
DACCON1 = %00000000
SRCON0 = %00000000
SRCON1 = %00000000
INTCON = %00000000
FVRCON = %00000000
MDCON = %00000000
BORCON = %00000000
SRCON0 = %00000000
SRCON1 = %00000000
PIE1 = %00000000
PIE2 = %00000000
PIE3 = %00000000
PIE4 = %00000000


CM1CON0 = %00000000
CM1CON1 = %00000000
CM2CON0 = %00000000
CM2CON1 = %00000000

'***************************************************************
'********************SET PORTS**********************************
'***************************************************************

''''''PORTA SETUP''''''''
ANSELA = %00000000
WPUA = %11001010
INLVLA = %00000000
LATA = %00010000
TRISA = %11111111

''''''PORTB SETUP''''''''
ANSELB = %00000000
WPUB = %11001111
INLVLB = %01110000
LATB = %00000000
TRISB = %11111111

''''''PORTC SETUP''''''''
ANSELC = %00000000
WPUC = %11111001
INLVLC = %00000000
LATC = %00000110
TRISC = %11111111

---

that was the jumped to routine that was interesting ...

just to see which commands you use for it.

BTW ... is there any special reason for that ???

Code:

---

OSCTUNE = %011111

---

Alain

That sets the oscillator tuning register to maximum frequency however, after seeing it, it looks as though I am missing a bit.

I also don't understand the other question you asked

I was just asking for the listing of the routine that "Bugs" ...

no more !

Quote:

---

Now when they press another button, the code does a jump (gosub) to a routine. When this happens, it turns the LED off.

---

Seeing the offending code would certainly help, which is what Alian is trying to say.

The program is probably starting over from the top for one reason or another, resetting the TRISA to 255 (all inputs), disabling the output drivers. My guess is that you're missing a RETURN at the end of the subroutine to which you jump with a GOSUB.

/Henrik.

It returns to the loop it came from. I will put up the routine causing the issue when I get back to my office.

Just curious... You mention setting the TRIS register to output, but do you also set the pin high?

TRISB = %11111110 'SET PORTB.0 TO OUTPUT
PORTB.0 = 1 'SET PORTB.0 OUTPUT HIGH

Or, perhaps your program completes the loop so quickly that the LED appears to go/ remain off? Perhaps a pause here or there will determine the matter? I find flashing the LED will, at times, make clear these anomalies. I am not so expert as to say with certainty, but... is setting the port state to zero (in the first lines) prior to defining the TRIS state (further down) effective in doing what you intend? Perhaps so, I have read (I believe) that the registers default to input - in which case, why define the TRIS at all? And, does doing so effect the port settings previously made?

Hmmm... It appears I have more questions than answers; how can that help? :)

I set the tris register to output and the port latch to low (I drive the LED by outputing low).

By setting the tris and port, shouldn't that stay in the state I set until a reboot or a part of code changes the state again?

I was told at some point that it's good practice to set your ports to 0 then set them to whatever you need after the rest of your registers are set. Maybe I was mis-informed on that but that is why I did it.

The processor is not re-setting for sure. I know this because there is an initial bootup sequence it goes through when booted up which would make it immediately clear that the processor reset.

I am hoping to get back in the office later and upload the routine it's jumping to although its just a simple repeat/until then returns. There are some pause and pauseus functions in there. Could that be an issue?

It returns to the loop it came from.