Apparent code size problem

[eetech]

Try this for the one above:

 
IF ErrCnt > 1 or FlagResult > 0 THEN GOSUB Houston

-------------------------------------------------


And try this for the one above:

IF OhmCheck = FAILED or FlagResult > 0 then GOSUB Houston

And try this separately:

IF OhmCheck = FAILED THEN
    ErrCnt = ErrCnt + 1     

    IF ErrCnt = 1 then 'first time gets a pass for a recheck
        Device = DISPLAY
        GOSUB SetCtrl
        LCDOUT $FE,1,"Chk Dckbill conn"
        LCDOUT $FE,$C0,"then retry test"
        PAUSE 1000
    else
        gosub Houston 
    endif
    
ENDIF


IF FlagResult > 0 THEN GOSUB Houston

Question: Do you set ErrCnt = 0 before the program starts running, or it gets some values from somewhere else?

In your code, it seems that it must be set to zero at initial power up before coming to "IF OhmCheck = FAILED THEN" condition.

Question: FlagResult is a hardware flag. So it can be 1 or 0 only, right? If yes, then why not use IF FlagResult = 1 instead of FlagResult <> 0 ?

FlagResult is a hardware flag, but it is a set of BIT flags so it can have a result other than 0 or 1.

Also, as Jerson said, we should see Houston subroutine.

May be there is something in it that makes things messed up.


--------------------------------

Both of those examples are fundamentally the same. The difference being your use of the IF without the ENDIF, which some languages (like PBP) allow.
I did try it though.

Yes, ErrCnt is set to 0 before usage.

FlagResult is a hardware flag, but it is a set of BIT flags so it can have a result other than 0 or 1.

The subroutine Houston uses Select Case to decode FlagResult and displays the appropriate error message. It does not return from there but goes into a continous loop because errors that cause Houston to be called are considered critical problems with either the instrument or the site being tested.

I may not have made myself clear in the original post, the problem does not occur because the code in question is run (the program never gets that far). The problem occurs when the first piece of code is replaced by the second.

[sinoteq]

This is what I had, I changed in one place and it died in another. If you check the asm file that you have on the NOT working program it is easy to see. Just look at the end address for each bank and most likely you will see Byte0 of a Word variable there. Byte1 will be in then next bank and this messes up all the RAM area for you even if you don't use that variable in the start of your program.

M