Error handling

From WikiPrizm
Revision as of 19:38, 2 December 2014 by Gbl08ma (talk | contribs) (It's the fourth line if we take the title as the first line. Just to be consistent with the previous section.)
Jump to navigationJump to search

This page has not been completed. Parts may be missing or reorganized before completed. Information is provided as-is and may have errors.

The OS sets up CPU parameters so that it can handle exceptions. In case of a software error not handled using "soft" means, namely during the execution of faulty add-ins, the OS exception handlers stop execution of the current process to some extent (but not completely: user timers will still run, for example), showing a pop-up on screen with title "SYSTEM ERROR" and some information about the fault:


From this pop-up, one can press the EXIT key to reboot. Usually this works, but it's possible that the system got into such a messed state, that it will not work, and one must reboot the calculator by other means. The EXE key is also supposed to do something, but as far as it is known, it does absolutely nothing.

In the case of system errors during execution of the child process, it is sometimes possible to press the MENU key and get into the Main Menu, open another add-in or built-in app (therefore ending the current child process, and switching to a new one), and the calculator will keep working as usual without the need for rebooting. However, this is not recommended and, depending on the cause of the error, may not work, causing further system errors or other kind of undefined behavior and, possibly, data loss. One very real possibility, is that file handles from the previous child process will not be closed when leaving a misbehaving app this way, and file operations may have strange behaviors, especially for files touched by the misbehaving program.


This appears to be a normal message box, probably opened with MsgBoxPush. In most cases, it's possible to see the last screen contents from the misbehaving application behind the message box. The first three line are always the same. The fourth line tells the type of exception and may be "ADDRESS(R)", "ADDRESS(W)", "PROTECTED(R)", "PROTECTED(W)", "Interrupt", "Illegal Code Err" or "TLB ERROR". More information about each error can be found in the Exception Types section. The fifth and sixth lines don't always appear; when they do, they provide information about the state of program execution at the time of the exception.

Exception Types

The fourth line on the System Error dialog tells you what exception the OS handled. This gives you an idea of what is wrong with the code at the PC. The Transition address is the address of the exception handler called. VBR is the address stored at 0xA0000000.


Causes: This exception is thrown if there is a data address error. This can be caused if a word is accessed across word boundary, a longword across a longword boundary, or a quadword across a quadword boundary. It is also possible that this may be called when an instruction address is used that is not word-aligned. The (x) will either be R or W if the exception occurred on the Read or the Write cycle.

VBR Offset: 0x100

Exception Code: 0x0E0 on read, 0x100 on write

Priority: 5


Causes: This is unconfirmed, however this may be caused by a read or write to protected memory. The (x) will either be R or W if the exception occurred on the Read or the Write cycle.

VBR Offset: 0x100

Exception Code: 0x0A0 on read, 0x0C0 on write

Priority: 7


Causes: This is caused by a TRAPA #imm (unconditional trap) assembly opcode. This is used for purposefully triggering an exception that is handled by external code.

VBR Offset: 0x100

Exception Code: 0x160

Priority: 4

An example of encountering this exception is by going to the diagnostic mode, pressing 3, 9, 2, F1. The "SYSTEM ERROR" message appears on screen with "INTERRUPT", but the target and PC lines are not shown. EXIT can't be used to reboot, despite what the text says.credits

Illegal Code Err

Causes: Assumed to be caused by either an unknown instruction being called or an opcode generated a general error (such as invalid usage of branch opcodes generating exceptions).

VBR Offset: 0x100

Exception Code: 0x180

Priority: 4


Causes: There was a memory access to the virtual memory that isn't mapped to a physical memory page in the UTLB page table (and possibly the ITLB page table if the access was from an instruction fetch) and the OS was unable to handle it. Note that the actual exception is normal behavior for the MMU and relies on the OS to handle it without generating errors. This occurs if the OS cannot handle it.

VBR Offset: 0x400

Exception Code: 0x040 if this was from a TLB miss in the UTLB cache from a read (Also a miss in the ITLB if this is an instruction fethc), 0x060 if this was from a TLB miss in the UTLB page table from a memory write.

Priority: 2 if from an ITLB miss, 6 if from a UTLB miss.

Graceful error handling

Sometimes the OS can handle a problem gracefully at a higher level, without crashing right down to a system error. This is the case with errors like "Data ERROR" (often shown when one tries to perform operations on files which were left open by another app), or "Application ERROR" (which has only been seen once by --Gbl08ma (talk) 18:37, 2 December 2014 (EST), when switching from a custom add-in running as eActivity strip back into the eActivity document. There was no apparent cause for the error).

Another example of a (mostly) gracefully handled problem is when the user formats the storage memory on the computer during a USB connection. In this case, "File System ERROR" is shown and certain operations will not be available until the user initializes the calculator using the Reset menu on the System app.

Some of these errors are mentioned in the "Error Message Table" section of the Appendix of the Prizm's software manual.