Assertions#
An assert is a check that should always be true when the program is executing correctly. Asserts are used to prevent the program from continuing to execute if some kind of problem is detected. Micrium products use asserts in several places for these reasons, and also to check the validity of several arguments passed to API functions before they are used. For information about how to use the asserts in an application context, or how to configure them, see the Micrium OS Asserts Programming Guide or RTOS Compile-Time Configuration pages. The asserts come in two distinct types, as listed below.
Debug Asserts#
The debug asserts (RTOS_ASSERT_DBG or APP_RTOS_ASSERT_DBG) are used in cases where the code cannot recover from what is currently happening; most of the time, this requires changes in the application's code. These debug asserts should help during the development phase of an application. For example, the debug asserts would catch invalid parameters passed to a function, or they could detect that a given function cannot be called when the system is in a particular state or with a given configuration. The user can define a macro or function to be called in case an assert fails, as explained on the RTOS Compile-Time Configuration page.
It is possible to disable the debug asserts by setting RTOS_CFG_ASSERT_DBG_ARG_CHK_EXT_MASK to 0u. This will speed code execution, and save space in memory or in code footprint (see RTOS Compile-Time Configuration ).
Critical Asserts#
Critical asserts (RTOS_ASSERT_CRITICAL and APP_RTOS_ASSERT_CRITICAL) are used in cases where the code reaches a point that should normally never be reached (for example, the default case of a switch statement for which every possible value is handled). If a critical assert is triggered, it means that the system is in an unknown state and that code execution should be halted before executing erroneous operations.
This kind of problem is often due to memory corruption (for example if a task's stack overflows and corrupts some other memory location). The user can define a macro or function to be called in case an assert fails (see RTOS Compile-Time Configuration ).
The 'critical' asserts cannot be disabled because they represent a failsafe. Since they are more rarely used than their debug counterpart, they should not slow the execution of the application or take too much space.