IPC@CHIP® RTOS-PPC – API Documentation

Header image

Main page


Each program may set an error handler function with this API. Each program's callback operates independently of other programs.

The system will automatically remove a program's error callback handler when the program terminates, or if the callback function itself causes an exception.

The callback excecutes in the context of a high priority system task which is dedicated to performing these system error handler callbacks into application programs. (This task is not present until the user installs a system error handler callback.) This kernel callback task is named _KCB and executes by default at priority 2. The user is free to change this task's priority to what ever is suitable for your system. This priority change could be made from any task, including from within the callback.

The RTX_CB_SUPV_MODE macro can optionally be applied to the 'vector' argument to force the system to perform the callback in Supervisor mode. By default, the callback will execute in User mode.

The callback function is invoked once for each system error that occurs after the point in time where the vector is installed by this API. A cumulative view of all system errors which have occurred since power up is available in the faults bit field member of the gSysPublicData data structure.

The callback function receives two input parameters:

  • error_code - Indicates which fault has occurred
  • details - Additional information whose context is specific to an error_code value. See table below. Where '0' is indicated in the table's details column, this parameter carries no information.





Pointer to a BiosFaultRecS structure containing more detailed information concerning the exception that has occured.

An MMU error would be a common source of such an exception. This reported exception may have occurred in another program. Only exceptions hit at task level are reported here. Exceptions occuring in an interrupt handler lead to an immediate system reset, so therefore are not reported here. Exceptions caught by an installed sTRY_CATCH will also not be reported here.



(Provisional, currently not implemented)


Task ID of thread which encountered this fault.

The unlucky task which hit this fault is suspended.


The TCP/IP heap memory limit [bytes]

The TCP/IP memory budget has been exhausted.


Task ID of thread which encountered this fault.

An allocation from the system heap failed.


  • 1 - Ethernet driver open failed
  • 2 - Ethernet device restart failed
  • 3 - Buffer release timeout occured

The Ethernet device driver has encountered a failure. In case of detail code 3 a buffer was not released by TCPIP, this could lead to corrupted TCPIP buffer.


Address of failed flash location

An A: drive flash write error has occurred with a resulting data loss.


Address of weak flash location

An A: drive flash write required more than a single attempt before verify showed correct contents.


Task ID of thread which encountered this fault.

An allocation attempt from system heap failed.


Task ID of thread which encountered this fault.

An attempt to increase the size of the program heap space has failed due to lack of available address space to extend this program's image. In some cases this problem can be avoided by reserving the program additional address space using the setSpaceReserve macro.


  • 1 - USB Host Controller reset failed

A hardware error has been detected.



The readout from the EEPROM where the system serial number is stored has failed.


Byte 3 (MSB):

  • 1 - Hub has an unexpected configuration.
  • 2 - Hub could not be handled. (e.g. communication error)
  • 3 - There's a problem with the power supply of an attached hub
  • 4 - Hub has detected an over current condition.
  • 5 - Hub has detected a general port error. (e.g. due to babble)

Byte 2:
Address of the corresponding hub. (0 refers to the root hub)
Byte 1:
Number of the resp. port. (0 refers to the hub itself, 1 to the first port etc.)
Byte 0 (LSB):
Reserved for future use (currently 0)

The USB hub driver encountered an error.


Watchdog manager handle for which the fault was encountered.

The process that has registered to the watchdog manager under the given handle has failed to refresh the watchdog manager in time.



This error code is used by the GCLIB: The communication between the IPC@CHIP® and the graphics controller failed.


User defined

These error codes are posted by user application programs with the BIOS_Set_Error() API.

[in] vector Callback function in user program. Set to NULL to remove a callback.
A callback vector previously set by this particular program, else NULL if none had been set. (Each program's vectors are handled independently of one another.)
SC2x3 V1.00 - CLIB V1.00
SC2x3 V1.10 - CLIB V1.05
See also:
BIOS_Set_Error API
ERRORS shell command
This API is not available in SC1x, SC2x and SC1x3 C-Library. The alternate BIOS_Install_Error_Handler() API may be used where compatibility is required.

Top of page | Main page

Copyright © 2018 Beck IPC GmbH
Generated on Thu Nov 1 13:20:15 2018 by Doxygen 1.6.1