Method running into the next one.

oodes · 2015-05-29 03:47

I have this sporadic issue where one method sometimes runs into the method directly below it . The method 'DisplayTemplate' is called frequently and on a few occasions (quite rare but still shouldnt be happening) it will 'overshoot' and print out the method below it on my LCD screen,(Usually just the first line or so). The Startupscreen1 method is only ever called at startup .
Any ideas what might cause this or had similar issues?
I thought it may be from a lack of allocated stack space for the cog in which its running and I recently upped it to 128 longs but it still occured.

PUB DisplayTemplate(Mode,MSG)|a,b
{{Templete used to display Current Status of ProGen}}
    case Mode
       0:       ' Non Promotional Product
            lcd.move(1,1)
            lcd.str(string(" NON PROMO PRODUCT  "))
            'b := strsize(@printerproduct)
            if lcdstrlength <19
                lcd.move((10-lcdstrlength/2),3)
                lcd.str(@printerproduct)
            else
                lcd.move(2,3)
                repeat a from 0 to 17
                    lcd.char(printerproduct.byte[a])
                    
                   
       1:       ' Promotional Product
            if lcdOneShot == 0                 'This is to prevent junk sometimes being displayed when changing over messages
                Pause(500)
                lcd.clear
                lcdOneShot:=1
                debug.str(string(13,"Lcd Oneshot executed!!!")) 
            lcd.move(1,1)
            b := lcdstrlength
            lcd.str(string("Batch:")) 
            if b <15     
                lcd.move(21 - b,1)                                            
                lcd.str(@printerproduct)
            else
              repeat a from 0 to 13
                lcd.char(printerproduct.byte[a])
            lcd.move(1,2)
            lcd.str(string("Balance:"))
            lcd.move(9,2)
            case (NoOfCodes-CurCodeNo)
                0..9:                           lcd.str(string("           "))
                10..99:                         lcd.str(string("          "))
                100..999:                       lcd.str(string("         "))
                1000..9999:                     lcd.str(string("        "))
                10000..99999:                   lcd.str(string("       "))
                100000..999999:                 lcd.str(string("      "))
                1000000..9999999:               lcd.str(string("     "))
                10000000..99999999:             lcd.str(string("    "))
                100000000..99999999:            lcd.str(string("   "))
            lcd.dec(NoOfCodes-CurCodeNo)
            a:=10-CharsPerCode/2
            if a//2 == 0
                a++
            lcd.move(a,3)
            lcd.str(@thecode)
            
            lcd.move(1,4)
            case LcdAlertCount
                0:
                    if MSG <> 0
                        lcd.str(MSG)
                    else
                        lcd.str(string("                    ")) 
                           
                1:   lcd.str(string("                    "))
            LcdAlertCount++
            if LcdAlertCount>1 
                LcdAlertCount:=0

PUB StartUpScreen1
{{When ProGen is switched on this screen appears followed by Startupscreen2,3 and 4}}
        
    lcd.clear
    lcd.move(6,1)                                 
    lcd.str(string("ProGen 125"))
    lcd.move(1,2)                                
    lcd.str(string(" UNIQUE CODE FEEDER"))
    lcd.move(1,3)
    lcd.str(@KernalVerNo)
    lcd.move(1,4)
    lcd.str(@VersionNo)

Electrodude · 2015-05-29 08:57

Can you please upload all of your source as a Propeller Archive? Otherwise, we have no way to tell how DisplayTemplate and StartUpScreen1 are called, what StartUpScreen2,3,4 look like and where they are called, what things could be using the stack, what objects lcd and debug are, what sizes any of your global variables are, etc.

localroger · 2015-05-30 15:27

Yeah intermittent problems like this are very often due to stack corruption, and methods "returning" to something other than what called them. This can happen because the method was started via cognew and the stack array isn't big enough or is specified wrong, or because some direct memory access method (perhaps pointers offset to local variables) is trashing memory that doesn't belong to it.

kuroneko · 2015-06-02 04:52

This is just the first issue I came across:

PUB GetInterfaceVersion(locPointer)|a ,LocRx
    repeat a from 0 to strsize(@Version)
      byte[locPointer++] := Version.byte[a] 
    [color="red"]locpointer.byte[a]:=0[/color]

The loop copies the version string including terminator (0..length). I believe the red line is intended to place said terminator but effectively writes a zero byte somewhere on the stack (locpointer.byte[idx] accesses memory starting at @locpointer, IOW relative to the method's parameter location). I'm not saying that this is the reason for the odd behaviour you're seeing but it's definitely fishy.

oodes · 2015-06-02 05:06

Noted and corrected. Thanks

I was testing it with this stackLength object recommended in the propellor manual, and i found that if i ran it on my lcdhander it was returning a stack length of 32 longs but if i used 32 longs it would cause issues

kuroneko · 2015-06-02 05:22

StartupScreen1 is only called when bit 16 is not set in Sts[0]. Could it be that the ErrorHandler stack is too small (thereby running into Sts[])?

oodes · 2015-06-02 05:33

Its possible I guess but I ran the stackLength object on the Errorhandler as well and it returned 22 longs. So 40 should be enough. However I have since increased all of the stack space allocations to 128 longs since and added a return to the DisplayTemplate template in an attempt to stop the overrun(no idea if that even helps) which is really just papering over the cracks. I haven't seen the issue arise since but its very sporadic so I'm not sure it solved the problem or not

Method running into the next one.

Comments