Technical details
Hardware errors are returned when a component of the system can no longer operate and must return a serious failure. The error range was defined in PRM 1-43 (Generating and handling errors), and expanded upon in RISC OS Select documentation. RISC OS Pyromaniac introduces another type of erro code.
The error numbers allocated all have their top 8 bits set to &80 and are reserved in groups of 256. The following groups are reserved:
Hex error number | Meaning |
---|---|
80000000 | Machine exceptions |
80000100 | Coprocessor exceptions |
80000200 | Floating point exceptions |
80000300 | Econet exceptions |
80000400 | Reserved (due to misallocation) |
80000500 | Reserved for interpreted exceptions (aborting regions in RISC OS Select) |
80000600 | VFP exceptions |
80000700 | RISC OS Pyromaniac exceptions |
Some of the machine exceptions are documented below, together with the RISC OS Pyromaniac exception.
Error messages
This error is generated by RISC OS Pyromaniac when no dedicated error number has been allocated and an exception is returned to the user. It is not strictly a hardware error, but may indicate a more serious problem with the system than a usual error. It may also indicate a lazy implementation which has not been given a proper error number.
This error is raised when an instruction which is not recognised by the CPU, or which is invalid at the current privilege level, is executed. During the processing of the error, the enviroment register dump will be updated with the registers at the time of the exception.
This error is raised when an attempt is made to execute code in a region of memory which is not available at the current privilege level. During the processing of the error, the enviroment register dump will be updated with the registers at the time of the exception.
This error is raised when an attempt is made to read from or write to a region of memory which is not available at the current privilege level. During the processing of the error, the enviroment register dump will be updated with the registers at the time of the exception.
This error was raised for a request for an area of memory which is not accessible by the system. On older systems higher regions of memory were not addressable by the CPU. It is no longer raised as the entire memory range is accessible in 32bit systems.
This error was raised went an unknown interrupt was triggered. It is no longer generated by the OS.
This error is generated by the OS when an attempt is made to execute code at address 0. During the processing of the error, the enviroment register dump will be updated with the registers at the time of the exception.
This error is geneated by the OS when it detects that one of the privileged mode stacks (SVC or IRQ) has become corrupted in a way that prevents the system from reporting its backtrace information.
This error is generated by the OS when an access is made to the memory at the base of the privileged mode stack. This indicates that the stack has become full. Earlier versions of RISC OS would report such overflows as a data abort.
This error is generated by the OS when it detects that one of the privileged mode stacks (SVC or IRQ) has become corrupted. Examples of corruption might include the stack pointer being out of range, the stack pointer being misaligned, or guard values being overwritten.
This error is generated by the OS when an exception occurs in the Python code providing the implemention of the processor emulation or OS interfaces. The Python backtrace and exception information may be reported on the host console, with the exception text reported as the RISC OS error message.
This error is generated by the OS when the configured limit of nested SWI calls is reached. Under RISC OS Pyromaniac, a limit is configurable for the number of SWI calls that may be made within one another. This limit is intended to protect against very complex system calls, or infinite recursion long before it would be caught by the Error_SVCStackOverflow error.