strange debug behaviour on 18M2

[hax]

I have been trying to chase down an issue in my programming. Not sure if I have found the bug yet but during my testing, I found something strange going on with the DEBUG command.

To see if my hardware is OK, I wrote a short program below.... as you can see, it polls the state of four inputs, and then sets the value of b1 to either 1,2,3 or 4 depending on which switch has been pressed.
The wait 20 command is there just to alert me to a reset, if the picaxe resets unexpectedly.

The problem is that on my debug screen, sometimes I get a b1 value of 99, which is technically impossible, as I always change the value to either 1,2,3 or 4 before the debug command is issued. Any ideas what is causing this? I'm starting to think a brownout or something... really pulling my hair out on this one!



wait 20

checkswitches:
b1=99
if pinc.1 = 1 then reset1
if pinc.0 = 1 then start1
if pinc.6 = 1 then advance5m
if pinc.2 = 1 then advance10m
goto checkswitches


reset1:
b1=1
pause 10
debug
goto checkswitches

start1:
b1=2
pause 10
debug
goto checkswitches



ladvance5m:
b1=3
pause 10
debug
goto checkswitches

advance10m:
b1=4
pause 10
debug
goto checkswitches

 

[hax]

Ah as quickly as I wrote this, I seem to have fixed it. I changed start1 and reset1 to different names, having a suspicion that they are reserved words now?

The whole story is that I am porting an 18x program to an 18m2 chip, and it seems the new chip does not like start1 or reset1 as a name. Guessing something to do with the multiple threading?

 

[srnet]

having a suspicion that they are reserved words now?

Checkout the 'reserved words' section of Manual_2, what does it say ?

 

[Technical]

Start1 starts another parallel task - see parallel tasks in part1 of the manual.