www.coridium.us/forum

two issues - they may be related. and one question [see the BTW] - this is on the BASICchip and the 812
in BasicTools - the stop button doesn't immediately halt execution. I have had as many as eight single "0" get processed and printed out on the screen
before everything settled down - did a BT stop button at a DEBUGIN prompt
'
putting a STOP in this program - did create a printout for a "Break:" BUT it also completed the program !!! to the END statement -
I didn't touch a key, move a mouse
[BTW what is the message trying to tell me to do to 'run' the program ?? is that the <CTRL> key carat symbol????]
'
choice = 0
print "choice time"
debugin choice
print "choice was ", choice
if choice = 1 then goto GO:
goto status
GO:
print " I am at go"
stop
print "am I done at go"
end
status:
print "I am at status"
stop
print "am I done at statuso"
end

****************************
Executing...

choice time
choice was 1
I am at go

Break:

@ hex [yy] - dump at hex yy words
! hex yy - write yy to hex
^ to run
am I done at go


... Finished in 4437 ms

the STOP button in BASICtools is never going to be immediate, you have delay of Microsoft mouse driver, interpret time of Tcl, delays in BASICtools to keep the board in sync with the PC, delay of Microsoft USB serial emulator, delay of FTDI USB driver, buffering on USB target side, and finally it sends a RESET, waits some more then sends the ESCape character, and then the firmware waits on the ARM for that character before either starting the user code or dropping into the BASIC monitor. In addition to that any PRINT statement buffers up characters to be sent back to the PC which happen by an interrupt routine that sends them when the UART transmitter is free.

As for your program example, I am looking, DEBUGIN is something we seldom use, opting for RXD(0) when communicating with the PC.

I can understand the BT 'stop' button delays - you explained it well.
'
but the inline STOP shouldn't have all that, PLUS it continued on to the end of the program, -- it basically printed the message and kept going
so the variables could have changed by the time I could call them up
'
when you get the DEBUGIN info, just add the STOP comments to it

It's the STOP continuing to run that I am looking at, don't know if it is a compiler issue or what, as it works fine on the ARM7s but those are ARM code not Thumb code.