LED turns off when jumping to a routine

[plyrathrt]

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

[Acetronics2]

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

no more !

[HenrikOlsson]

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.

[plyrathrt]

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

[Amoque]

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?

[plyrathrt]

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?