Target States, Exceptions

It's good that you are here! There actually is something to learn about the target states!


In the RUN state, the VM is executing your application. This doesn't mean that some code is being executed all the time.

Being an event-based system, TiOS executes event handlers in response to events. If there are no events to take care of, the VM is idle and ready to handle the next event when it comes.

The values of variables in the Watch pane are not updated while the VM is executing.


The PAUSE, BREAK, and ABORT states indicate that the VM is stopped and no code is being executed.

The master process still continues with its business and keeps generating events. These events will wait in the event queue and be handled by the VM when execution resumes.

The values of variables in the Watch pane are updated as soon as the target exits the RUN state.


Below are the differences between these three states:

The PAUSE state means that execution was paused while the VM was idle, i.e. not executing any event handlers.

The program pointer is not displayed because no procedure (function) is being executed.

This state can only occur if you pause the execution manually (Debug > Pause) or reboot your target (Debug > Restart).


The BREAK state means that execution was paused while the VM was busy executing an event handler.

The program pointer will be displayed.

This state can happen if you pause execution manually (Debug > Pause) or execution stops at a breakpoint.


The ABORT state means that execution was paused because of an exception. This also means that the VM was busy executing an event handler.

The program pointer will be displayed. Below is a table of possible exceptions:

Code

Description

Halt in debug mode?

Halt in release mode?

HALT

Caused by execution of the sys.halt method. This is a self-generated exception, so not really a "real" one.

Yes

Yes

DIV0

Division by zero.

Yes

No

OOR(1)

Out of range (i.e., an attempt to access past the last array member). The actual erroneous access will be prevented.

Yes

No

FPERR

Floating point error.

Yes

No

IOC(2)

Invalid opcode.

Yes

Yes

OUM(2)

Access outside of user memory.

Yes

Yes

TDLF(2)

Failed to load the binary library.

Yes

Yes


  1. The range correctness checks are only performed for Tibbo BASIC arrays, which are "safe." TIBBO C arrays are not safe and TiOS has no way to catch out-of-range access situations for them.
  2. You should never see these errors. Let us know if you catch any of them!