Odd behavior if too many instructions

[dksoba]

Try adding ...

DEFINE LOADER_USED 1 ' Bootloader Used

That is defined in generic_include.inc. I moved it to my main pbp file and removed that include, and it still does the same thing.

Does this have something to do with stacksize? If you overflow the stack... what happens?

Matt

[Darrel Taylor]

Does this have something to do with stacksize? If you overflow the stack... what happens?

It has nothing to do with the stack.
It just makes sure nothing is in the first 4 words.
Those locations are needed for the Bootloader.

And when you overflow the stack on 16F's ... Nothing happens.
It's when you return, that you may end up in the wrong place.

What else is in your Includes?
Can you post them too?
<br>

[dksoba]

My main code (updated):

http://pastebin.com/m7513a97d

Includes:

generic_include.inc:
http://pastebin.com/m1be5ca8f

LCD_Init_PortD.inc:
http://pastebin.com/m17a1888d

ADC10:
http://pastebin.com/m3b596568


In my updated code, something bizarre happens. My setup has an optical encoder w/channels A/B. When I start my program, it drops into "Main" after initializing variables and such. Main displays the current position of the encoder. As my code stands, it's fast and normal. The LCD updates w/the correct position at the speed it's supposed to. If I make ONE simple modification, if I comment out DEBUG_STACK declaration on line 30, all of a sudden for no apparent reason, the update rate of the LCD will be 0.5-1s. No idea what's going on. This isn't the only thing to trigger that. If I then comment out the PID_Loop routine, it'll be fast again... I'm so confused and frustrated and I'm not sure wtf is happening. Oh yea, Even if the LCD updates slowly, it still displays the correct position, which tells me that the interrupt service routine is working.

Thanks,
Matt

[Darrel Taylor]

Ok, this is probably what's happening.

You've got just enough variables that 1 or 2 are getting pushed into BANK1.
In particular _portb_masked.

_portb_masked is used in the interrupt handler, but the Bank isn't being changed. So it ends up overwriting memory in BANK0.
Where it's located makes it overwrite PBP's system registers at R1.

If you comment out the DEBUG_STACK variable like you mentioned, the _portb_masked variable moves and then overwrites PBP's R0 system var.

As the placement of the variable moves, so does the apparent problem that it causes, which corresponds with your symptoms.
If you were to remove two more variables, _portb_masked would no longer be in BANK1, and it would probably run correctly.

Unless you are handling the Banking, any variables you use at the ASM level should be declared in BANK0.

encoder_history VAR BYTE BANK0:encoder_history = 0 'Store the current and last state of channelA/B of the encoder
portb_masked VAR BYTE BANK0:portb_masked = 0 'Masked port B to have only the encoder channels
interrupt_debug           VAR BYTE BANK0: interrupt_debug = 0

HTH,

[dksoba]

Thanks! That seems to have done the trick. I'm using MicroCode Studio Plus, is there anyway to see what variables are stored in what banks?

Also, more importantly, I'm not currently saving/restoring the FSR register when I go into my interrupt service routine. I'm not sure if any of the PBP commands use indirect addressing, do they?

If they do, I can do the following:

'create fsrsave
fsrsave VAR byte bank0 system 'What does the "system" do anyways?

...

ASM
...
movf FSR,W
movwf fsrsave

...do the routine

...at the end, restore stuff, and then before retfie
movf fsrsave,W
movwf FSR
retfie

Right? I'm learning so damn much from this project. It's not even an electrical engineering project, it's a mechanical engineering project, but I like to take it to the next level to learn more .

Thanks,
Matt

[Darrel Taylor]

You can look in the .LST file to see the addresses where each variable is assigned.

You can also File > Import the .cof file into MPLAB then View > File Registers > Symbolic Tab.
It's a lot easier to read than the .lst file.
Of course, you need the datasheet to figure out where the banks are.

And there are many PBP commands that use the FSR.
But none of the statements in your ISR do, so right now there's no need to save/restore it.

Cheers,

[dksoba]

If I go over 1 page of code (2k words, right?) is there anything I need to worry about w/my current code? I know the pbp code will take care of itself, but my ASM ISR might not. I do use PCLATH for the table jump, so that should be fine. And my GOTO's should be fine so long as the entire ISR is in page0, right?

Thanks,
Matt